From never at openjdk.java.net Fri Oct 1 17:10:28 2021 From: never at openjdk.java.net (Tom Rodriguez) Date: Fri, 1 Oct 2021 17:10:28 GMT Subject: RFR: 8218885: Restore pop_frame and force_early_return functionality for Graal In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote: > This logic no longer seems to be necessary since the adjustCompilationLevel callback has been removed. I don't see any easy way to run the suggested command at the moment through mach5. We've already pushed this change into our JDK17 repos and once we have a snapshot GraalVM based on that I could do it, but it will probably take at least 2-3 weeks for all those bits to be promoted. Why are we running the jck jvmti tests on this since they weren't failing originally? The problem test list from the commit http://hg.openjdk.java.net/jdk/jdk12/rev/f5fd8eefae0f is all nsk and com.sun.jdi tests. I ran those locally with jtreg using a GraalVM built from a patched JDK and they all passed. Is that sufficient? ------------- PR: https://git.openjdk.java.net/jdk/pull/5625 From kvn at openjdk.java.net Fri Oct 1 17:28:33 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 1 Oct 2021 17:28:33 GMT Subject: RFR: 8218885: Restore pop_frame and force_early_return functionality for Graal In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote: > This logic no longer seems to be necessary since the adjustCompilationLevel callback has been removed. Yes, running locally with GraalVM is fine. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5625 From dlong at openjdk.java.net Fri Oct 1 20:34:29 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 1 Oct 2021 20:34:29 GMT Subject: RFR: 8218885: Restore pop_frame and force_early_return functionality for Graal In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote: > This logic no longer seems to be necessary since the adjustCompilationLevel callback has been removed. Marked as reviewed by dlong (Reviewer). Make sure to test with -Xcomp. ------------- PR: https://git.openjdk.java.net/jdk/pull/5625 From sspitsyn at openjdk.java.net Fri Oct 1 20:56:30 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 1 Oct 2021 20:56:30 GMT Subject: RFR: 8218885: Restore pop_frame and force_early_return functionality for Graal In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 17:07:23 GMT, Tom Rodriguez wrote: > Why are we running the jck jvmti tests on this since they weren't failing originally? The problem test list from the commit http://hg.openjdk.java.net/jdk/jdk12/rev/f5fd8eefae0f is all nsk and com.sun.jdi tests. The reason to disable PopFrame and ForceEarlyReturn with Graal were failing jck tests. They are not JTreg tests, handled differently and have no ProblemList. I'd suggest to integrate your fix now and deal with this potential problem when Graal is back. ------------- PR: https://git.openjdk.java.net/jdk/pull/5625 From sspitsyn at openjdk.java.net Fri Oct 1 20:56:30 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 1 Oct 2021 20:56:30 GMT Subject: RFR: 8218885: Restore pop_frame and force_early_return functionality for Graal In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote: > This logic no longer seems to be necessary since the adjustCompilationLevel callback has been removed. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5625 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 1 21:08:44 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 1 Oct 2021 21:08:44 GMT Subject: RFR: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Message-ID: There are few places in code where manual `while` loop is used with Iterator to iterate over Collection. Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone. It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. Similar cleanups: * https://bugs.openjdk.java.net/browse/JDK-8258006 * https://bugs.openjdk.java.net/browse/JDK-8257912 ------------- Commit messages: - [PATCH] Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/5630/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5630&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274662 Stats: 16 lines in 2 files changed: 0 ins; 8 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5630/head:pull/5630 PR: https://git.openjdk.java.net/jdk/pull/5630 From github.com+741251+turbanoff at openjdk.java.net Fri Oct 1 21:12:57 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Fri, 1 Oct 2021 21:12:57 GMT Subject: RFR: 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management [v2] In-Reply-To: References: Message-ID: > There are a few places in code, where manual `for` loop is used with Iterator to iterate over Collection. > Instead of manual `for` cycles, it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. > Similar cleanups: > 1. [JDK-8274016](https://bugs.openjdk.java.net/browse/JDK-8274016) java.desktop > 2. [JDK-8274237](https://bugs.openjdk.java.net/browse/JDK-8274237) java.base > 3. [JDK-8274261](https://bugs.openjdk.java.net/browse/JDK-8274261) jdk.jcmd Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management small code-style fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5695/files - new: https://git.openjdk.java.net/jdk/pull/5695/files/e3884614..263e8682 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5695&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5695&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5695.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5695/head:pull/5695 PR: https://git.openjdk.java.net/jdk/pull/5695 From amenkov at openjdk.java.net Fri Oct 1 21:24:25 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 1 Oct 2021 21:24:25 GMT Subject: RFR: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 08:58:01 GMT, Andrey Turbanov wrote: > There are few places in code where manual `while` loop is used with Iterator to iterate over Collection. > Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5630 From ccheung at openjdk.java.net Fri Oct 1 21:36:33 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 1 Oct 2021 21:36:33 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v2] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 16:23:34 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed miss return after file read failed Looks good. Just a few minor comments. src/hotspot/share/cds/filemap.cpp line 283: > 281: assert(base_archive_name_size() != 0, "_base_archive_name_size not set"); > 282: assert(base_archive_path_offset() != 0, "_base_archive_path_offset not set"); > 283: assert(header_size() > sizeof(*this), "_base_archive_name_size not included in head size?"); Typo: head -> header src/hotspot/share/cds/filemap.cpp line 1154: > 1152: // read the base archive name > 1153: size_t name_size = (size_t)header->_base_archive_name_size; > 1154: assert(name_size != 0, "None default base archive, name size should not be zero!"); Typo: None default -> Non-default test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java line 226: > 224: > 225: // modify _base_archive_path_offet to not zero > 226: System.out.println("\n8. modify _base_archive_path_offset to not zero\n"); Suggestion: not zero -> non-zero test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java line 109: > 107: > 108: // 2. Make header size biger than the archive size > 109: System.out.println("\n2. Make header size biger than the archive size"); Typo: biger -> larger test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java line 124: > 122: int fileHeaderSize = (int)CDSArchiveUtils.fileHeaderSize(copiedJsa); > 123: int baseArchivePathOffset = CDSArchiveUtils.baseArchivePathOffset(copiedJsa); > 124: CDSArchiveUtils.modifyHeaderIntField(copiedJsa, CDSArchiveUtils.offsetBaseArchivePathOffset, baseArchivePathOffset + 1024); In line 124, could `baseArchivePathOffset` be used instead of `CDSArchiveUtils.offsetBaseArchivePathOffset` ? test/lib/jdk/test/lib/cds/CDSArchiveUtils.java line 139: > 137: int size = baseArchiveNameSize(jsaFile); > 138: int baseArchivePathOffset = (int)readInt(jsaFile, offsetBaseArchivePathOffset, 4); > 139: return readString(jsaFile, baseArchivePathOffset, size - 1); // exclude including ending '\0' Suggestion on the comment: // exclude the terminating ?\0? ------------- Changes requested by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5768 From cjplummer at openjdk.java.net Fri Oct 1 22:33:27 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 1 Oct 2021 22:33:27 GMT Subject: RFR: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent In-Reply-To: References: Message-ID: <3P0K8fnJHwftP9llrZBu-n9gCCqT9rezg1h__TiYSbw=.74a1d783-05a7-4ca0-944c-5a928a62d444@github.com> On Wed, 22 Sep 2021 08:58:01 GMT, Andrey Turbanov wrote: > There are few places in code where manual `while` loop is used with Iterator to iterate over Collection. > Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5630 From sspitsyn at openjdk.java.net Fri Oct 1 22:56:27 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 1 Oct 2021 22:56:27 GMT Subject: RFR: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 08:58:01 GMT, Andrey Turbanov wrote: > There are few places in code where manual `while` loop is used with Iterator to iterate over Collection. > Instead of manual `while` cycles it's preferred to use _enhanced-for_ cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5630 From sspitsyn at openjdk.java.net Fri Oct 1 23:00:29 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 1 Oct 2021 23:00:29 GMT Subject: RFR: 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management [v2] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 21:12:57 GMT, Andrey Turbanov wrote: >> There are a few places in code, where manual `for` loop is used with Iterator to iterate over Collection. >> Instead of manual `for` cycles, it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. >> Similar cleanups: >> 1. [JDK-8274016](https://bugs.openjdk.java.net/browse/JDK-8274016) java.desktop >> 2. [JDK-8274237](https://bugs.openjdk.java.net/browse/JDK-8274237) java.base >> 3. [JDK-8274261](https://bugs.openjdk.java.net/browse/JDK-8274261) jdk.jcmd > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management > small code-style fixes Thank you for the update. It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5695 From lzang at openjdk.java.net Mon Oct 4 06:38:44 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 4 Oct 2021 06:38:44 GMT Subject: RFR: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field could be sucessfully parsed. > We think this class can be removed for 2 reasons: > 1. The gzip heap dump file generated by `jhsdb` command does not contain the "blocksize" header field, so the GzipRandomAccess can not parse the generated file successfully. > 2. The `GzipInputStream` could be used instead and then gziped heap dump file generated from both `jcmd`/`jmap` and `jhsdb jmap` could be parsed using same logic. > Options Dear Chris @plummercj, May I ask your help to take look at this again? Do you think my expaination about "use of decompressed file" is OK? Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From ysuenaga at openjdk.java.net Mon Oct 4 06:51:29 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 4 Oct 2021 06:51:29 GMT Subject: RFR: 8274670: Improve version string handling in SA Message-ID: Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { // Throw exception if different release versions: // .-b throw new VMVersionMismatchException(saVersion, vmRelease); } else { // Otherwise print warning to allow mismatch not release versions // during development. System.err.println("WARNING: Hotspot VM version " + vmRelease + " does not match with SA version " + saVersion + "." + " You may see unexpected results. "); } It seems to expect to allow the deference in option string only. For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. ------------- Commit messages: - 8274670: Improve version string handling in SA Changes: https://git.openjdk.java.net/jdk/pull/5797/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274670 Stats: 18 lines in 2 files changed: 1 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5797/head:pull/5797 PR: https://git.openjdk.java.net/jdk/pull/5797 From github.com+741251+turbanoff at openjdk.java.net Mon Oct 4 12:10:10 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 4 Oct 2021 12:10:10 GMT Subject: RFR: 8274670: Improve version string handling in SA In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 13:08:58 GMT, Yasumasa Suenaga wrote: > Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. > > Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. > > > if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && > vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { > // Throw exception if different release versions: > // .-b > throw new VMVersionMismatchException(saVersion, vmRelease); > } else { > // Otherwise print warning to allow mismatch not release versions > // during development. > System.err.println("WARNING: Hotspot VM version " + vmRelease + > " does not match with SA version " + saVersion + > "." + " You may see unexpected results. "); > } > > > It seems to expect to allow the deference in option string only. > For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. > > I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMVersionMismatchException.java line 37: > 35: > 36: public String getMessage() { > 37: return "Supported versions are " + supportedVersions.toString() + Why do you call to `toString()` explicitly here? String concatenation will do it for you without it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5797 From ysuenaga at openjdk.java.net Mon Oct 4 13:02:37 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 4 Oct 2021 13:02:37 GMT Subject: RFR: 8274670: Improve version string handling in SA [v2] In-Reply-To: References: Message-ID: > Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. > > Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. > > > if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && > vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { > // Throw exception if different release versions: > // .-b > throw new VMVersionMismatchException(saVersion, vmRelease); > } else { > // Otherwise print warning to allow mismatch not release versions > // during development. > System.err.println("WARNING: Hotspot VM version " + vmRelease + > " does not match with SA version " + saVersion + > "." + " You may see unexpected results. "); > } > > > It seems to expect to allow the deference in option string only. > For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. > > I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove toString() calls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5797/files - new: https://git.openjdk.java.net/jdk/pull/5797/files/c5d7c20d..346e1418 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5797&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5797&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5797/head:pull/5797 PR: https://git.openjdk.java.net/jdk/pull/5797 From ysuenaga at openjdk.java.net Mon Oct 4 13:02:41 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 4 Oct 2021 13:02:41 GMT Subject: RFR: 8274670: Improve version string handling in SA [v2] In-Reply-To: References: Message-ID: <8JltAbn4Rd5697nBgRF3k4nyPvv2TUwj_BWOhQhMstU=.3db33338-8b44-4ec5-a689-d3163bc0b1c5@github.com> On Mon, 4 Oct 2021 12:07:02 GMT, Andrey Turbanov wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove toString() calls > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMVersionMismatchException.java line 37: > >> 35: >> 36: public String getMessage() { >> 37: return "Supported versions are " + supportedVersions.toString() + > > Why do you call to `toString()` explicitly here? String concatenation will do it for you without it. I'm not particular about `toString()` call, so I removed them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5797 From rrich at openjdk.java.net Mon Oct 4 13:59:23 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Oct 2021 13:59:23 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. Message-ID: The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: All threads suspended by the thread-level **resume** command or the VM-level **resume** command are resumed as many times as necessary for them to run. It should be changed to All threads suspended by the thread-level **suspend** command or the VM-level **suspend** command are resumed as many times as necessary for them to run. [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) ------------- Commit messages: - Correct JDWP spec, Dispose command. Changes: https://git.openjdk.java.net/jdk/pull/5804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274716 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5804/head:pull/5804 PR: https://git.openjdk.java.net/jdk/pull/5804 From alanb at openjdk.java.net Mon Oct 4 14:26:10 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 4 Oct 2021 14:26:10 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 13:44:44 GMT, Richard Reingruber wrote: > The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed as many times as necessary for them to run. > > It should be changed to > > All threads suspended by the thread-level **suspend** command or the VM-level > **suspend** command are resumed as many times as necessary for them to run. > > [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) It looks like this typo goes all the way back to JDK 1.2 but was not noticed. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5804 From rrich at openjdk.java.net Mon Oct 4 14:26:19 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Oct 2021 14:26:19 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend Message-ID: This change fixes the deadlock described in the JBS-bug by: * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` * Notifying on `threadLock` after resuming all threads in `threadControl_reset()` The PR has 3 commits: The first commit delays the cleanup actions after leaving the loop in `debugLoop_run()` because of a Dispose command. The delay allows to reproduce the deadlock running the dispose003 test with the command make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 The second commit contains the fix described above. With it the deadlock cannot be reproduced anymore. The third commit removes the diagnostic code introduced with the first commit again. The fix passed our nightly regression testing: JCK and JTREG, also in Xcomp mode with fastdebug and release builds on all platforms. ------------- Commit messages: - Remove delay in cleanup again. - Fix that prevents deadlock. - Delay cleanup after JDWP Dispose command to trigger deadlock in the test dispose003 Changes: https://git.openjdk.java.net/jdk/pull/5805/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5805&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274687 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5805.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5805/head:pull/5805 PR: https://git.openjdk.java.net/jdk/pull/5805 From rrich at openjdk.java.net Mon Oct 4 14:33:08 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 4 Oct 2021 14:33:08 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 14:22:50 GMT, Alan Bateman wrote: > > > It looks like this typo goes all the way back to JDK 1.2 but was not noticed. Thanks for reviewing. JDK 1.2 is surely long ago. Nevertheless not too many will have read that sentence since then I reckon ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/5804 From minqi at openjdk.java.net Mon Oct 4 17:42:29 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 4 Oct 2021 17:42:29 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v3] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed output according to comment, fixed member accessor of CDSArchiveUtils ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/032e819c..913aa64b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=01-02 Stats: 54 lines in 4 files changed: 23 ins; 0 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Mon Oct 4 17:50:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 4 Oct 2021 17:50:27 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v4] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/913aa64b..033c5763 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From cjplummer at openjdk.java.net Mon Oct 4 18:24:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 4 Oct 2021 18:24:08 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 13:44:44 GMT, Richard Reingruber wrote: > The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed as many times as necessary for them to run. > > It should be changed to > > All threads suspended by the thread-level **suspend** command or the VM-level > **suspend** command are resumed as many times as necessary for them to run. > > [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) Can you update the copyright please? I checked the JDI spec and it looks correct there, which is actually surprising since errors like this usually appear in both specs. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5804 From cjplummer at openjdk.java.net Mon Oct 4 18:36:15 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 4 Oct 2021 18:36:15 GMT Subject: RFR: 8274670: Improve version string handling in SA [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 13:02:37 GMT, Yasumasa Suenaga wrote: >> Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. >> >> Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. >> >> >> if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && >> vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { >> // Throw exception if different release versions: >> // .-b >> throw new VMVersionMismatchException(saVersion, vmRelease); >> } else { >> // Otherwise print warning to allow mismatch not release versions >> // during development. >> System.err.println("WARNING: Hotspot VM version " + vmRelease + >> " does not match with SA version " + saVersion + >> "." + " You may see unexpected results. "); >> } >> >> >> It seems to expect to allow the deference in option string only. >> For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. >> >> I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove toString() calls Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5797 From iklam at openjdk.java.net Mon Oct 4 21:37:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 4 Oct 2021 21:37:10 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v4] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 17:50:27 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comment Changes requested by iklam (Reviewer). src/hotspot/share/cds/filemap.cpp line 173: > 171: memset((void*)this, 0, sizeof(FileMapInfo)); > 172: _is_static = is_static; > 173: size_t c_header_size; FileMapInfo::FileMapInfo() is called in two places: (1) When reading an archive -- _header should not be initialized here. It should be done inside FileMapInfo::init_from_file. (2) When writing an archive -- I think we should move the _header initialization to FileMapInfo::populate_header(). src/hotspot/share/cds/filemap.cpp line 197: > 195: _header->set_base_archive_path_offset(0); > 196: _header->set_base_archive_name_size(0); > 197: _header->set_header_size((unsigned int)header_size); The above 3 lines can be replaced by lines 203 .. 205, and 203 .. 205 can be deleted. src/hotspot/share/cds/filemap.cpp line 200: > 198: _header->set_has_platform_or_app_classes(true); > 199: if (!is_static) { > 200: _header->set_base_archive_is_default(FLAG_IS_DEFAULT(SharedArchiveFile)); There's no need for a separate _base_archive_is_default field. We are using the base archive if base_archive_name_size == 0. src/hotspot/share/cds/filemap.cpp line 1057: > 1055: GenericCDSFileMapHeader* header = (GenericCDSFileMapHeader*)os::malloc(sz, mtInternal); > 1056: memset((void*)header, 0, sz); > 1057: size_t n = os::read(fd, (void*)header, (unsigned int)sz); There are currently 3 different places where we read the GenericCDSFileMapHeader, find out the size, and then read the real header. - FileMapInfo::get_base_archive_name_from_header - FileMapInfo::check_archive - FileMapInfo::init_from_file I think these should be consolidated into a single function. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From cjplummer at openjdk.java.net Tue Oct 5 05:34:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 05:34:09 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 14:07:18 GMT, Richard Reingruber wrote: > This change fixes the deadlock described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` after resuming all threads in `threadControl_reset()` > > The PR has 3 commits: > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()` because of a Dispose command. The delay allows to reproduce the deadlock > running the dispose003 test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit contains the fix described above. With it the deadlock > cannot be reproduced anymore. > > The third commit removes the diagnostic code introduced with the first commit again. > > The fix passed our nightly regression testing: JCK and JTREG, also in Xcomp mode with fastdebug and release builds on all platforms. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750: > 748: while (node && node->suspendCount > 0) { > 749: /* Resume requires the event handlerLock so we have to release it */ > 750: eventHandler_unlock(); I'm not so sure this is always safe. It might be fine in the context of resetting the connection, but not during normal debug agent operations. It allows for another event to be processed when the lock is suppose to keep event processing serialized. What happens for example if we hit the `Thread.resume()` breakpoint again on a different thread? It might be best to limit doing this only when `threadControl_reset()` is currently executing (you could set a flag there), although it seems more like a band aid than a proper fix. I could imagine there might still be scenarios were releasing the lock during reset might be problematic, although probably extremely unlikely to ever be noticed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From cjplummer at openjdk.java.net Tue Oct 5 05:37:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 05:37:06 GMT Subject: RFR: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field could be sucessfully parsed. > We think this class can be removed for 2 reasons: > 1. The gzip heap dump file generated by `jhsdb` command does not contain the "blocksize" header field, so the GzipRandomAccess can not parse the generated file successfully. > 2. The `GzipInputStream` could be used instead and then gziped heap dump file generated from both `jcmd`/`jmap` and `jhsdb jmap` could be parsed using same logic. > Options Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From cjplummer at openjdk.java.net Tue Oct 5 05:37:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 05:37:07 GMT Subject: RFR: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: On Sun, 26 Sep 2021 08:07:46 GMT, Lin Zang wrote: >> test/lib/jdk/test/lib/hprof/parser/Reader.java line 99: >> >>> 97: // Possible gziped file, try decompress it and get the stack trace. >>> 98: in.close(); >>> 99: String deCompressedFile = "heapdump" + System.currentTimeMillis() + ".hprof"; >> >> Is it necessary to create a file with the decompressed output rather than just stream the decompressed output to a FileInputStream? > > Hi @plummercj, > Sorry for late response, I tried to avoid using the decompressed file, but it seems not simple as I expected. > The reason is that at line 121, the HprofReader require the filename and it use this file to create a ReadBuffer internally, and a RandomAccessFile will be created using the filename. > So I think may be it is not easy to make the change here, and maybe we could track it using a new bug if necessary, which may change the HprofReader implementation. > What do you think? Yes, it's fine then the way it currently is implemented. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From github.com+741251+turbanoff at openjdk.java.net Tue Oct 5 07:11:23 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 5 Oct 2021 07:11:23 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi Message-ID: There are few places in code where manual while loop is used with Iterator to iterate over Collection. Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. Similar cleanups: * https://bugs.openjdk.java.net/browse/JDK-8258006 * https://bugs.openjdk.java.net/browse/JDK-8257912 ------------- Commit messages: - [PATCH] Replace 'while' cycles with iterator with enhanced-for in jdk.jdi Changes: https://git.openjdk.java.net/jdk/pull/5577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274755 Stats: 82 lines in 9 files changed: 0 ins; 35 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/5577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5577/head:pull/5577 PR: https://git.openjdk.java.net/jdk/pull/5577 From github.com+741251+turbanoff at openjdk.java.net Tue Oct 5 07:17:20 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 5 Oct 2021 07:17:20 GMT Subject: RFR: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Message-ID: Pass cause exception as constructor parameter is shorter and easier to read. ------------- Commit messages: - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.management - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.management Changes: https://git.openjdk.java.net/jdk/pull/5552/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274757 Stats: 50 lines in 10 files changed: 0 ins; 32 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5552.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5552/head:pull/5552 PR: https://git.openjdk.java.net/jdk/pull/5552 From alanb at openjdk.java.net Tue Oct 5 07:29:10 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 5 Oct 2021 07:29:10 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 This code pre-dates for-each, the changes look okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5577 From rrich at openjdk.java.net Tue Oct 5 07:38:28 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 5 Oct 2021 07:38:28 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2] In-Reply-To: References: Message-ID: > The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed as many times as necessary for them to run. > > It should be changed to > > All threads suspended by the thread-level **suspend** command or the VM-level > **suspend** command are resumed as many times as necessary for them to run. > > [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Updated copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5804/files - new: https://git.openjdk.java.net/jdk/pull/5804/files/97396416..1d896c41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5804/head:pull/5804 PR: https://git.openjdk.java.net/jdk/pull/5804 From rrich at openjdk.java.net Tue Oct 5 07:43:09 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 5 Oct 2021 07:43:09 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:20:42 GMT, Chris Plummer wrote: > > > Can you update the copyright please? Sure, thanks! > I checked the JDI spec and it looks correct there, which is actually surprising since errors like this usually appear in both specs. Yes I noticed this too. Thanks for reviewing, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/5804 From sspitsyn at openjdk.java.net Tue Oct 5 07:52:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 07:52:10 GMT Subject: RFR: 8274670: Improve version string handling in SA [v2] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 13:02:37 GMT, Yasumasa Suenaga wrote: >> Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. >> >> Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. >> >> >> if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && >> vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { >> // Throw exception if different release versions: >> // .-b >> throw new VMVersionMismatchException(saVersion, vmRelease); >> } else { >> // Otherwise print warning to allow mismatch not release versions >> // during development. >> System.err.println("WARNING: Hotspot VM version " + vmRelease + >> " does not match with SA version " + saVersion + >> "." + " You may see unexpected results. "); >> } >> >> >> It seems to expect to allow the deference in option string only. >> For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. >> >> I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove toString() calls Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5797 From sspitsyn at openjdk.java.net Tue Oct 5 07:59:07 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 07:59:07 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 07:38:28 GMT, Richard Reingruber wrote: >> The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: >> >> All threads suspended by the thread-level **resume** command or the VM-level >> **resume** command are resumed as many times as necessary for them to run. >> >> It should be changed to >> >> All threads suspended by the thread-level **suspend** command or the VM-level >> **suspend** command are resumed as many times as necessary for them to run. >> >> [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5804 From dfuchs at openjdk.java.net Tue Oct 5 10:39:09 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 5 Oct 2021 10:39:09 GMT Subject: RFR: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 20:45:36 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. Nice simplification. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5552 From rrich at openjdk.java.net Tue Oct 5 13:58:15 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 5 Oct 2021 13:58:15 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 05:31:37 GMT, Chris Plummer wrote: > I'm not so sure this is always safe. It might be fine in the context of > resetting the connection, but not during normal debug agent operations. It > allows for another event to be processed when the lock is suppose to keep > event processing serialized. What happens for example if we hit the > `Thread.resume()` breakpoint again on a different thread? I agree that this is probably not safe. E.g. when releasing handlerLock the handler chain for EI_BREAKPOINT could be modified which is being iterated in the caller function event_callback(). https://github.com/openjdk/jdk/blob/8609ea55acdcc203408f58f7bf96ea9228aef613/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c#L647-L673 I should have checked before. > It might be best to limit doing this only when `threadControl_reset()` is > currently executing (you could set a flag there), although it seems more like > a band aid than a proper fix. I could imagine there might still be scenarios > were releasing the lock during reset might be problematic, although probably > extremely unlikely to ever be noticed. I looked at threadControl_resumeThread(). It appears to me that resuming a thread is not possible while some thread is waiting in blockOnDebuggerSuspend() because threadControl_resumeThread() locks handlerLock. https://github.com/openjdk/jdk/blob/32811026ce5ecb1d27d835eac33de9ccbd51fcbf/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c#L1485 Am I missing something? Maybe the code in handleAppResumeBreakpoint() could moved to doPendingTasks()? ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From amenkov at openjdk.java.net Tue Oct 5 18:58:07 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 5 Oct 2021 18:58:07 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From sspitsyn at openjdk.java.net Tue Oct 5 19:51:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 19:51:10 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 src/jdk.jdi/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java line 881: > 879: // copy the eventRequests to avoid ConcurrentModificationException > 880: for (EventRequest eventRequest : new ArrayList<>(eventRequests)) { > 881: ((EventRequestImpl) eventRequest).delete(); I'm not sure the `eventRequest` needs to be wrapped into new `ArrayList`. I think, this should work without it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From sspitsyn at openjdk.java.net Tue Oct 5 19:58:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 19:58:10 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Hi Andrey, It looks good in general but I've inlined one comment. Also, I need to mention it again that the formatting rules for casts do not require space as in here: `(InterfaceTypeImpl) interfaceType` Additional rule is at least to follow the local style in each file. There are plenty of such spaces added in this PR. Could you, please, fix them? Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From sspitsyn at openjdk.java.net Tue Oct 5 20:07:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 20:07:10 GMT Subject: RFR: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module In-Reply-To: References: Message-ID: <3BIxmo44EZZsMWwxDu4G1AqiCKo_qYQuwWpeXGQZJsI=.273b7e4b-b16b-4df0-983f-2139931c67f0@github.com> On Thu, 16 Sep 2021 20:45:36 GMT, Andrey Turbanov wrote: > Pass cause exception as constructor parameter is shorter and easier to read. I agree with Daniel, it is nice simplification. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5552 From cjplummer at openjdk.java.net Tue Oct 5 20:11:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 20:11:06 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From cjplummer at openjdk.java.net Tue Oct 5 20:11:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 20:11:07 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 19:48:06 GMT, Serguei Spitsyn wrote: >> There are few places in code where manual while loop is used with Iterator to iterate over Collection. >> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. >> >> Similar cleanups: >> * https://bugs.openjdk.java.net/browse/JDK-8258006 >> * https://bugs.openjdk.java.net/browse/JDK-8257912 > > src/jdk.jdi/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java line 881: > >> 879: // copy the eventRequests to avoid ConcurrentModificationException >> 880: for (EventRequest eventRequest : new ArrayList<>(eventRequests)) { >> 881: ((EventRequestImpl) eventRequest).delete(); > > I'm not sure the `eventRequest` needs to be wrapped into new `ArrayList`. I think, this should work without it. It seems odd at first, but seems to have been done purposefully. Perhaps it has to do with the fact that delete() is being called, which does appear to also end up deleting the request from the list (see line 167). I don't think you want to be deleting from or adding to a collection that you are iterating over. ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From cjplummer at openjdk.java.net Tue Oct 5 20:32:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 20:32:07 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 13:54:46 GMT, Richard Reingruber wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750: >> >>> 748: while (node && node->suspendCount > 0) { >>> 749: /* Resume requires the event handlerLock so we have to release it */ >>> 750: eventHandler_unlock(); >> >> I'm not so sure this is always safe. It might be fine in the context of resetting the connection, but not during normal debug agent operations. It allows for another event to be processed when the lock is suppose to keep event processing serialized. What happens for example if we hit the `Thread.resume()` breakpoint again on a different thread? >> >> It might be best to limit doing this only when `threadControl_reset()` is currently executing (you could set a flag there), although it seems more like a band aid than a proper fix. I could imagine there might still be scenarios were releasing the lock during reset might be problematic, although probably extremely unlikely to ever be noticed. > >> I'm not so sure this is always safe. It might be fine in the context of >> resetting the connection, but not during normal debug agent operations. It >> allows for another event to be processed when the lock is suppose to keep >> event processing serialized. What happens for example if we hit the >> `Thread.resume()` breakpoint again on a different thread? > > I agree that this is probably not safe. E.g. when releasing handlerLock the > handler chain for EI_BREAKPOINT could be modified which is being iterated in > the caller function event_callback(). > > https://github.com/openjdk/jdk/blob/8609ea55acdcc203408f58f7bf96ea9228aef613/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c#L647-L673 > > I should have checked before. > >> It might be best to limit doing this only when `threadControl_reset()` is >> currently executing (you could set a flag there), although it seems more like >> a band aid than a proper fix. I could imagine there might still be scenarios >> were releasing the lock during reset might be problematic, although probably >> extremely unlikely to ever be noticed. > > I looked at threadControl_resumeThread(). It appears to me that resuming a > thread is not possible while some thread is waiting in blockOnDebuggerSuspend() > because threadControl_resumeThread() locks handlerLock. > > https://github.com/openjdk/jdk/blob/32811026ce5ecb1d27d835eac33de9ccbd51fcbf/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c#L1485 > > Am I missing something? > > Maybe the code in handleAppResumeBreakpoint() could moved to doPendingTasks()? Regarding threadControl_resumeThread() it does appear that it would block, as would threadControl_resumeAll(), which seems problematic in that blockOnDebuggerSuspend() won't exit until the suspendCount == 0. So it's unclear to me how this is suppose to work if a resume() can't be done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From lkorinth at openjdk.java.net Tue Oct 5 20:39:30 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 5 Oct 2021 20:39:30 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: > The basic problem is that we are relying on undefined behaviour, as documented in the code: > > // This whole business of passing information from ResourceObj::operator new > // to the ResourceObj constructor via fields in the "object" is technically UB. > // But it seems to work within the limitations of HotSpot usage (such as no > // multiple inheritance) with the compilers and compiler options we're using. > // And it gives some possibly useful checking for misuse of ResourceObj. > > > I am removing the undefined behaviour by passing the type of allocation through a thread local variable. > > This solution has some advantages: > 1) it is not UB > 2) it is simpler and easier to understand > 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) > 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. > > When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. > > I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. > > This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. > > I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. > > Testing on debug build tier1-3 > Testing on release build tier1 Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: Use a thread local buffer so that the compiler might reorder operator new. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5387/files - new: https://git.openjdk.java.net/jdk/pull/5387/files/d8acedb0..c9d45906 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=01-02 Stats: 91 lines in 5 files changed: 46 ins; 27 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/5387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5387/head:pull/5387 PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 5 20:57:07 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 5 Oct 2021 20:57:07 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Sun, 26 Sep 2021 04:50:07 GMT, Kim Barrett wrote: >> Thanks Ioi for making me adding the assert!!! The sequencing of the allocation function and the arguments to the constructor is not what I thought, so my "solution" is not working. I am unsure how to resolve this in a good way. We could probably have a small thread local collection of (type, address) pairs, but I wonder if it is not better removing this debug information altogether. It is to my knowledge only used in GrowableArray (to limit the type of its internal allocations) and to hinder delete on resource allocated objects. > > A collection of (type, address) pairs is still problematic. It still requires assuming that the address of the derived object is the same as the address of the ResourceObj subobject, which isn't guaranteed, though the current mechanism also depends on that being true. I think there might be other places in HotSpot where we're making that assumption too, unfortunately. I used your idea of using a triplet to be sure that the derived object is within the created allocation. This solution can still fail if using multiple inheritance (no regression from today) or if allocation is done recursively (but then an assert will trigger). I think this is better than what we have today. If someone wants to remove this debug information in the future I would not argue against it. In the latest update I changed two classes that faked to be `ResourceObj`. I made them proper `ResourceObj`. I also made `allocation_type` a uint8_t and changed the code a bit so that `operator new` does not call `operator new`. I also made `BufferSize` 5. This could be anything >= 2 for clang at the moment, an assert will trigger if this size is too small. I have run the tests on tier1-tier3 on linux-x64, linux-x64-debug, linux-x86-debug, macosx-x64-debug, windows-x64-debug. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From cjplummer at openjdk.java.net Tue Oct 5 21:00:12 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 5 Oct 2021 21:00:12 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:28:36 GMT, Chris Plummer wrote: >>> I'm not so sure this is always safe. It might be fine in the context of >>> resetting the connection, but not during normal debug agent operations. It >>> allows for another event to be processed when the lock is suppose to keep >>> event processing serialized. What happens for example if we hit the >>> `Thread.resume()` breakpoint again on a different thread? >> >> I agree that this is probably not safe. E.g. when releasing handlerLock the >> handler chain for EI_BREAKPOINT could be modified which is being iterated in >> the caller function event_callback(). >> >> https://github.com/openjdk/jdk/blob/8609ea55acdcc203408f58f7bf96ea9228aef613/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c#L647-L673 >> >> I should have checked before. >> >>> It might be best to limit doing this only when `threadControl_reset()` is >>> currently executing (you could set a flag there), although it seems more like >>> a band aid than a proper fix. I could imagine there might still be scenarios >>> were releasing the lock during reset might be problematic, although probably >>> extremely unlikely to ever be noticed. >> >> I looked at threadControl_resumeThread(). It appears to me that resuming a >> thread is not possible while some thread is waiting in blockOnDebuggerSuspend() >> because threadControl_resumeThread() locks handlerLock. >> >> https://github.com/openjdk/jdk/blob/32811026ce5ecb1d27d835eac33de9ccbd51fcbf/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c#L1485 >> >> Am I missing something? >> >> Maybe the code in handleAppResumeBreakpoint() could moved to doPendingTasks()? > > Regarding threadControl_resumeThread() it does appear that it would block, as would threadControl_resumeAll(), which seems problematic in that blockOnDebuggerSuspend() won't exit until the suspendCount == 0. So it's unclear to me how this is suppose to work if a resume() can't be done. It seems if we had a test case where the debugger did a ThreadReference.suspend(), then the debuggee did a Thread.resume() on the same thread, and then debugger did a ThreadReference.resume(), it would block, and with no way to unblock it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From darcy at openjdk.java.net Tue Oct 5 21:51:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 5 Oct 2021 21:51:31 GMT Subject: Integrated: 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 21:39:52 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > on macosx-x64. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5829 From dcubed at openjdk.java.net Tue Oct 5 21:51:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 5 Oct 2021 21:51:31 GMT Subject: Integrated: 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 Message-ID: A trivial fix to ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64. ------------- Commit messages: - 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 Changes: https://git.openjdk.java.net/jdk/pull/5829/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5829&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274797 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5829/head:pull/5829 PR: https://git.openjdk.java.net/jdk/pull/5829 From dcubed at openjdk.java.net Tue Oct 5 21:51:32 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 5 Oct 2021 21:51:32 GMT Subject: Integrated: 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 21:44:40 GMT, Joe Darcy wrote: >> A trivial fix to ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java >> on macosx-x64. > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5829 From dcubed at openjdk.java.net Tue Oct 5 21:51:32 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 5 Oct 2021 21:51:32 GMT Subject: Integrated: 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 21:39:52 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > on macosx-x64. This pull request has now been integrated. Changeset: d4e8712c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/d4e8712c0acc786e64f81ad29e54e6e50134f0e0 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8274797: ProblemList resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java on macosx-x64 Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/5829 From sspitsyn at openjdk.java.net Tue Oct 5 22:24:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 5 Oct 2021 22:24:08 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:06:08 GMT, Chris Plummer wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java line 881: >> >>> 879: // copy the eventRequests to avoid ConcurrentModificationException >>> 880: for (EventRequest eventRequest : new ArrayList<>(eventRequests)) { >>> 881: ((EventRequestImpl) eventRequest).delete(); >> >> I'm not sure the `eventRequest` needs to be wrapped into new `ArrayList`. I think, this should work without it. > > It seems odd at first, but seems to have been done purposefully. Perhaps it has to do with the fact that delete() is being called, which does appear to also end up deleting the request from the list (see line 167). I don't think you want to be deleting from or adding to a collection that you are iterating over. You are right, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From minqi at openjdk.java.net Tue Oct 5 22:32:30 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 5 Oct 2021 22:32:30 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Added a helper class to facilitate checking archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/033c5763..1a88076f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=03-04 Stats: 267 lines in 4 files changed: 114 ins; 111 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From amenkov at openjdk.java.net Tue Oct 5 22:40:20 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 5 Oct 2021 22:40:20 GMT Subject: RFR: 8274621: NullPointerException because listenAddress[0] is null Message-ID: The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. Initially the predicate was called only for STDOUT; >From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". Also updated javadoc to reflect actual behavior. ------------- Commit messages: - Added synchronization between stdout and stderr warmup predicates Changes: https://git.openjdk.java.net/jdk/pull/5830/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5830&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274621 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5830.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5830/head:pull/5830 PR: https://git.openjdk.java.net/jdk/pull/5830 From ysuenaga at openjdk.java.net Wed Oct 6 00:40:11 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 6 Oct 2021 00:40:11 GMT Subject: Integrated: 8274670: Improve version string handling in SA In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 13:08:58 GMT, Yasumasa Suenaga wrote: > Use [java.lang.Runtime.Version](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Runtime.Version.html) to check the version of debugee. > > Currently `checkVMVersion()` in `sun.jvm.hotspot.runtime.VM` has following code to check the version of debugee. > > > if (saVersion.indexOf('-') == saVersion.lastIndexOf('-') && > vmVersion.indexOf('-') == vmVersion.lastIndexOf('-')) { > // Throw exception if different release versions: > // .-b > throw new VMVersionMismatchException(saVersion, vmRelease); > } else { > // Otherwise print warning to allow mismatch not release versions > // during development. > System.err.println("WARNING: Hotspot VM version " + vmRelease + > " does not match with SA version " + saVersion + > "." + " You may see unexpected results. "); > } > > > It seems to expect to allow the deference in option string only. > For example, `saVersion` is "17+35", and `vmVersion` is "17+35-2724", then it should be allowed because release version (17+35) is same. However current code would not do so. > > I guess this code is not based on [JEP 223](https://openjdk.java.net/jeps/223) (New Version-String Scheme) because the comment says ".-b". Fortunately we have `Runtime.Version` to handle version strings. We should refactor with it. This pull request has now been integrated. Changeset: 986ee5d0 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/986ee5d0bfd407dc1b7ce75c7c94b6585bfb497d Stats: 15 lines in 2 files changed: 1 ins; 1 del; 13 mod 8274670: Improve version string handling in SA Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5797 From sspitsyn at openjdk.java.net Wed Oct 6 01:45:06 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 6 Oct 2021 01:45:06 GMT Subject: RFR: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field could be sucessfully parsed. > We think this class can be removed for 2 reasons: > 1. The gzip heap dump file generated by `jhsdb` command does not contain the "blocksize" header field, so the GzipRandomAccess can not parse the generated file successfully. > 2. The `GzipInputStream` could be used instead and then gziped heap dump file generated from both `jcmd`/`jmap` and `jhsdb jmap` could be parsed using same logic. > Options Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From sspitsyn at openjdk.java.net Wed Oct 6 01:56:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 6 Oct 2021 01:56:15 GMT Subject: RFR: 8274621: NullPointerException because listenAddress[0] is null In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). > The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". > Also updated javadoc to reflect actual behavior. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5830 From iklam at openjdk.java.net Wed Oct 6 04:21:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 6 Oct 2021 04:21:08 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 22:32:30 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Added a helper class to facilitate checking archive Looks good overall. Just a few nits. src/hotspot/share/cds/filemap.cpp line 278: > 276: } > 277: > 278: // Do not check _magic, it's not been set yet. I think you can get rid of this comment by moving line 228 .. 231 after line 233. src/hotspot/share/cds/filemap.cpp line 1099: > 1097: lseek(_fd, _header->_base_archive_path_offset, SEEK_SET); // position to correct offset. > 1098: size_t n = os::read(_fd, *target, (unsigned int)name_size); > 1099: if (n != name_size) { I think there's no need to do another read. The base name string is already inside the buffer that was read on line 1079. You can just do a `strncpy` into `*target` src/hotspot/share/cds/filemap.cpp line 1205: > 1203: } > 1204: > 1205: _header = (FileMapHeader*)os::malloc(gen_header->_header_size, mtInternal); There's no need to allocate and read the header again. It's already in gen_header. This should be enough: _header = (FileMapHeader*)gen_header; src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c line 369: > 367: > 368: // check file magic > 369: if (header._generic_header._magic != CDS_ARCHIVE_MAGIC) { Use `header.magic()` instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From rrich at openjdk.java.net Wed Oct 6 06:43:05 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 6 Oct 2021 06:43:05 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:56:43 GMT, Chris Plummer wrote: >> Regarding threadControl_resumeThread() it does appear that it would block, as would threadControl_resumeAll(), which seems problematic in that blockOnDebuggerSuspend() won't exit until the suspendCount == 0. So it's unclear to me how this is suppose to work if a resume() can't be done. > > It seems if we had a test case where the debugger did a ThreadReference.suspend(), then the debuggee did a Thread.resume() on the same thread, and then debugger did a ThreadReference.resume(), it would block, and with no way to unblock it. I'll see if I can implement such a test. Also I have I prototype that defers the actions of handleAppResumeBreakpoint() until doPendingTasks() is running. This seems to work in the various jdi/jdwp tests which likely do not cover the functionality very well though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:00:34 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:00:34 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v2] In-Reply-To: References: Message-ID: <4mRnMbNaE6Au48JIp7VTRvFy6v4oMYce6sMHzLDXc2Y=.8dc07513-44ab-409f-abd2-e8bac0540d13@github.com> On Tue, 5 Oct 2021 19:55:12 GMT, Serguei Spitsyn wrote: >There are plenty of such spaces added in this PR. >Could you, please, fix them? Thank you for review. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 07:00:34 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 07:00:34 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v2] In-Reply-To: References: Message-ID: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi remove redundant spaces before casts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5577/files - new: https://git.openjdk.java.net/jdk/pull/5577/files/7e93b316..1de15c21 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5577&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5577&range=00-01 Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5577/head:pull/5577 PR: https://git.openjdk.java.net/jdk/pull/5577 From lkorinth at openjdk.java.net Wed Oct 6 09:50:08 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Wed, 6 Oct 2021 09:50:08 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: <4aTOtDeBp6oPKbZwwW16Fp6YnuhxAh3vJvM4VxgZRQI=.22d277b7-f7e2-4a4b-8121-4c303fb4dfdf@github.com> On Tue, 5 Oct 2021 20:39:30 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Use a thread local buffer so that the compiler might reorder operator new. I should probably remove MemRegionClosureRO and let DirtyCardToOopClosure directly inherit ResourceObj instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From rrich at openjdk.java.net Wed Oct 6 14:13:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 6 Oct 2021 14:13:11 GMT Subject: RFR: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 14:07:18 GMT, Richard Reingruber wrote: > This change fixes the deadlock described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` after resuming all threads in `threadControl_reset()` > > The PR has 3 commits: > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()` because of a Dispose command. The delay allows to reproduce the deadlock > running the dispose003 test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit contains the fix described above. With it the deadlock > cannot be reproduced anymore. > > The third commit removes the diagnostic code introduced with the first commit again. > > The fix passed our nightly regression testing: JCK and JTREG, also in Xcomp mode with fastdebug and release builds on all platforms. I've implemented a test that shows the jdwp agent deadlocks also trying to resume one/all threads if a thread is waiting in `blockOnDebuggerSuspend`. I will open a new pr that will include the test and a new attempt to fix the issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From rrich at openjdk.java.net Wed Oct 6 14:13:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 6 Oct 2021 14:13:11 GMT Subject: Withdrawn: 8274687: JDWP can deadlock VM if Java thread waits in blockOnDebuggerSuspend In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 14:07:18 GMT, Richard Reingruber wrote: > This change fixes the deadlock described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` after resuming all threads in `threadControl_reset()` > > The PR has 3 commits: > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()` because of a Dispose command. The delay allows to reproduce the deadlock > running the dispose003 test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit contains the fix described above. With it the deadlock > cannot be reproduced anymore. > > The third commit removes the diagnostic code introduced with the first commit again. > > The fix passed our nightly regression testing: JCK and JTREG, also in Xcomp mode with fastdebug and release builds on all platforms. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5805 From minqi at openjdk.java.net Wed Oct 6 16:36:19 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 16:36:19 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 04:17:16 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c line 369: > >> 367: >> 368: // check file magic >> 369: if (header._generic_header._magic != CDS_ARCHIVE_MAGIC) { > > Use `header.magic()` instead? header is a structure of CDSFileMapHeaderBase, unless we cast it to FileMapHeader. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Wed Oct 6 16:41:10 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 16:41:10 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 04:09:32 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/hotspot/share/cds/filemap.cpp line 1099: > >> 1097: lseek(_fd, _header->_base_archive_path_offset, SEEK_SET); // position to correct offset. >> 1098: size_t n = os::read(_fd, *target, (unsigned int)name_size); >> 1099: if (n != name_size) { > > I think there's no need to do another read. The base name string is already inside the buffer that was read on line 1079. You can just do a `strncpy` into `*target` FileHeaderHelper only read sizeof(GenericCDSFileMapHeader) which is the stable information for reading other information and checking the archive. It does not include name in the buffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Wed Oct 6 16:47:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 16:47:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 04:15:06 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/hotspot/share/cds/filemap.cpp line 1205: > >> 1203: } >> 1204: >> 1205: _header = (FileMapHeader*)os::malloc(gen_header->_header_size, mtInternal); > > There's no need to allocate and read the header again. It's already in gen_header. This should be enough: > > > _header = (FileMapHeader*)gen_header; see above reply. We need read the full _header_size for _header. Also note that helper class will delete gen_header when out of scope. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Wed Oct 6 17:01:31 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 17:01:31 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v6] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed comment for magic check, fixed _file_offset to _header_size ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/1a88076f..b804dbc6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=04-05 Stats: 8 lines in 1 file changed: 3 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From iklam at openjdk.java.net Wed Oct 6 17:05:12 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 6 Oct 2021 17:05:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v6] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 17:01:31 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comment for magic check, fixed _file_offset to _header_size src/hotspot/share/cds/filemap.cpp line 1045: > 1043: class FileHeaderHelper { > 1044: int _fd; > 1045: GenericCDSFileMapHeader* _header; This should be changed to `GenericCDSFileMapHeader _header;`. That way, you don't need to malloc and free it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From iklam at openjdk.java.net Wed Oct 6 17:05:12 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 6 Oct 2021 17:05:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 16:44:25 GMT, Yumin Qi wrote: >> src/hotspot/share/cds/filemap.cpp line 1205: >> >>> 1203: } >>> 1204: >>> 1205: _header = (FileMapHeader*)os::malloc(gen_header->_header_size, mtInternal); >> >> There's no need to allocate and read the header again. It's already in gen_header. This should be enough: >> >> >> _header = (FileMapHeader*)gen_header; > > see above reply. We need read the full _header_size for _header. Also note that helper class will delete gen_header when out of scope. I see. I think your current code is fine. Note that the current code writes the header as a FileMapHeader, but it reads it as both a FileMapHeader and a CDSFileMapHeaderBase. So it has the basic assumption `FileMapHeader::_generic_header` is at offset 0 of FileMapHeader. Therefore, in FileHeaderHelper::initialize, we should add an assert: static_assert(offsetof(FileMapHeader, _generic_header) == 0, "must be"); ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Wed Oct 6 17:48:30 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 17:48:30 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v7] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Change FileHeaderHelper::_header to value of non-ptr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/b804dbc6..81bd3a12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=05-06 Stats: 13 lines in 1 file changed: 0 ins; 8 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 18:15:15 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 18:15:15 GMT Subject: Integrated: 8274464: Remove redundant stream() call before forEach in java.* modules In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 07:12:25 GMT, Andrey Turbanov wrote: > 8274464: Remove redundant stream() call before forEach in java.* modules This pull request has now been integrated. Changeset: f3cedbe9 Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/f3cedbe9288e7aea8d5603a2dc9bdc2661c391a6 Stats: 8 lines in 4 files changed: 0 ins; 3 del; 5 mod 8274464: Remove redundant stream() call before forEach in java.* modules Reviewed-by: dfuchs, amenkov, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/5520 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 18:27:13 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 18:27:13 GMT Subject: Integrated: 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 10:51:12 GMT, Andrey Turbanov wrote: > There are a few places in code, where manual `for` loop is used with Iterator to iterate over Collection. > Instead of manual `for` cycles, it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. > Similar cleanups: > 1. [JDK-8274016](https://bugs.openjdk.java.net/browse/JDK-8274016) java.desktop > 2. [JDK-8274237](https://bugs.openjdk.java.net/browse/JDK-8274237) java.base > 3. [JDK-8274261](https://bugs.openjdk.java.net/browse/JDK-8274261) jdk.jcmd This pull request has now been integrated. Changeset: 9945f7a0 Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/9945f7a0744db2470bcfa856e8f831b6a6eb2de8 Stats: 19 lines in 3 files changed: 0 ins; 10 del; 9 mod 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management Reviewed-by: cjplummer, sspitsyn, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5695 From dfuchs at openjdk.java.net Wed Oct 6 18:27:13 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 6 Oct 2021 18:27:13 GMT Subject: RFR: 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management [v2] In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 21:12:57 GMT, Andrey Turbanov wrote: >> There are a few places in code, where manual `for` loop is used with Iterator to iterate over Collection. >> Instead of manual `for` cycles, it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: javac compiler generates similar code when compiling enhanced-for cycle. >> Similar cleanups: >> 1. [JDK-8274016](https://bugs.openjdk.java.net/browse/JDK-8274016) java.desktop >> 2. [JDK-8274237](https://bugs.openjdk.java.net/browse/JDK-8274237) java.base >> 3. [JDK-8274261](https://bugs.openjdk.java.net/browse/JDK-8274261) jdk.jcmd > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274318: Replace 'for' cycles with iterator with enhanced-for in java.management > small code-style fixes Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5695 From sspitsyn at openjdk.java.net Wed Oct 6 18:54:09 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 6 Oct 2021 18:54:09 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v2] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 07:00:34 GMT, Andrey Turbanov wrote: >> There are few places in code where manual while loop is used with Iterator to iterate over Collection. >> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. >> >> Similar cleanups: >> * https://bugs.openjdk.java.net/browse/JDK-8258006 >> * https://bugs.openjdk.java.net/browse/JDK-8257912 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi > remove redundant spaces before casts There are still extra space in the file InvokableTypeImpl.java. src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java line 144: > 142: List interfaces = interfaces(); > 143: for (InterfaceType interfaceType : interfaces) { > 144: InterfaceTypeImpl interfaze = (InterfaceTypeImpl) interfaceType; There is still extra space at line 144. src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java line 161: > 159: */ > 160: for (InterfaceType interfaceType : interfaces()) { > 161: InterfaceTypeImpl interfaze = (InterfaceTypeImpl) interfaceType; Extra space at line 163. src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java line 178: > 176: list.addAll(interfaces()); > 177: for (InterfaceType interfaceType : immediate) { > 178: InterfaceTypeImpl interfaze = (InterfaceTypeImpl) interfaceType; Extra space at line 163. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5577 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 19:00:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 19:00:35 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v2] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 18:51:16 GMT, Serguei Spitsyn wrote: >There are still extra space in the file InvokableTypeImpl.java. updated `InvokableTypeImpl.java` too ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From github.com+741251+turbanoff at openjdk.java.net Wed Oct 6 19:00:35 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 6 Oct 2021 19:00:35 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v3] In-Reply-To: References: Message-ID: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi remove empty space before casts in InvokableTypeImpl too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5577/files - new: https://git.openjdk.java.net/jdk/pull/5577/files/1de15c21..669f2a31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5577&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5577&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5577/head:pull/5577 PR: https://git.openjdk.java.net/jdk/pull/5577 From minqi at openjdk.java.net Wed Oct 6 19:10:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 19:10:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 17:01:58 GMT, Ioi Lam wrote: >> see above reply. We need read the full _header_size for _header. Also note that helper class will delete gen_header when out of scope. > > I see. I think your current code is fine. > > Note that the current code writes the header as a FileMapHeader, but it reads it as both a FileMapHeader and a CDSFileMapHeaderBase. So it has the basic assumption `FileMapHeader::_generic_header` is at offset 0 of FileMapHeader. Therefore, in FileHeaderHelper::initialize, we should add an assert: > > > static_assert(offsetof(FileMapHeader, _generic_header) == 0, "must be"); This caused compiling error: since FileHeaderHelper is not a friend of FileMapHeader so no access to its fields: error: 'GenericCDSFileMapHeader CDSFileMapHeaderBase::_generic_header' is inaccessible within this context ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From cjplummer at openjdk.java.net Wed Oct 6 19:34:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 6 Oct 2021 19:34:06 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:00:35 GMT, Andrey Turbanov wrote: >> There are few places in code where manual while loop is used with Iterator to iterate over Collection. >> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. >> >> Similar cleanups: >> * https://bugs.openjdk.java.net/browse/JDK-8258006 >> * https://bugs.openjdk.java.net/browse/JDK-8257912 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi > remove empty space before casts in InvokableTypeImpl too I also was going to comment on the space after each cast, but then I went in search of an openjdk java style guide and found this: http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html Which says to use a single space "After the closing parenthesis of a cast". Personally I don't like it, and I don't know if this is an official guide, but it's the only openjdk style guide I could find. I did also find the following, which says the same, but is not specifically for openjdk: https://google.github.io/styleguide/javaguide.html#s4.6-whitespace ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From minqi at openjdk.java.net Wed Oct 6 21:53:30 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 6 Oct 2021 21:53:30 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8] In-Reply-To: References: Message-ID: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Add offset check for _generic_header in populate_header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5768/files - new: https://git.openjdk.java.net/jdk/pull/5768/files/81bd3a12..753adaa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=06-07 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768 PR: https://git.openjdk.java.net/jdk/pull/5768 From coleenp at openjdk.java.net Wed Oct 6 23:37:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 23:37:18 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name Message-ID: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> 8273956: Add checking for rank values This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. Tested with tier1-8 at one point in time and just retested with tier1-6. ------------- Commit messages: - 8274004: Change 'nonleaf' rank name Changes: https://git.openjdk.java.net/jdk/pull/5845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274004 Stats: 445 lines in 41 files changed: 98 ins; 117 del; 230 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From dcubed at openjdk.java.net Wed Oct 6 23:45:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Oct 2021 23:45:04 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. The PR description mentions: `8273956: Add checking for rank values` but the PR synopsis is: `8274004: Change 'nonleaf' rank name` ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From dcubed at openjdk.java.net Wed Oct 6 23:55:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Oct 2021 23:55:10 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Just do ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From dholmes at openjdk.java.net Thu Oct 7 02:15:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Oct 2021 02:15:06 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Hi Coleen, Overall this looks good! But shouldn't the test: test/hotspot/gtest/runtime/test_safepoint_locks.cpp be replaced by one that checks we lock with/without a safepoint check for a safepoint/nonsafepoint lock respectively? (Or does that test already exist elsewhere?). Also should there not be a gtest to verify your Rank overlap checking? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From sspitsyn at openjdk.java.net Thu Oct 7 05:17:05 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 05:17:05 GMT Subject: RFR: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi [v3] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:00:35 GMT, Andrey Turbanov wrote: >> There are few places in code where manual while loop is used with Iterator to iterate over Collection. >> Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. >> It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. >> >> Similar cleanups: >> * https://bugs.openjdk.java.net/browse/JDK-8258006 >> * https://bugs.openjdk.java.net/browse/JDK-8257912 > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi > remove empty space before casts in InvokableTypeImpl too Marked as reviewed by sspitsyn (Reviewer). We had HotSpot convention about it. Not sure where it is located now. One of the important rules was to follow the file (area) local style if possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From iklam at openjdk.java.net Thu Oct 7 06:09:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 7 Oct 2021 06:09:07 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:53:30 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Add offset check for _generic_header in populate_header LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5768 From kbarrett at openjdk.java.net Thu Oct 7 06:27:10 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 7 Oct 2021 06:27:10 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:39:30 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > Use a thread local buffer so that the compiler might reorder operator new. Changes requested by kbarrett (Reviewer). src/hotspot/share/asm/codeBuffer.cpp line 143: > 141: NOT_PRODUCT(clear_strings()); > 142: > 143: assert(_default_oop_recorder.allocated_on_stack_or_embedded(), "should be embedded object"); It might have been better to do this name change separately, to reduce distraction. src/hotspot/share/asm/codeBuffer.hpp line 369: > 367: // addresses in a sibling section. > 368: > 369: class CodeBuffer: public ResourceObj DEBUG_ONLY(COMMA private Scrubber) { Deriving from ResourceObj rather than the previous fakery seems good. I think the multiple-inheritance derivation from Scrubber could be removed, instead adding ~CodeBuffer to do the zapping. src/hotspot/share/asm/codeBuffer.hpp line 376: > 374: // CodeBuffers must be allocated on the stack except for a single > 375: // special case during expansion which is handled internally. This > 376: // is done to guarantee proper cleanup of resources. This comment seems dangling now that the associated operator definitions have been removed. src/hotspot/share/classfile/stackMapFrame.hpp line 66: > 64: > 65: StackMapFrame(const StackMapFrame& cp) : > 66: ResourceObj(), Good find. src/hotspot/share/gc/g1/g1Allocator.hpp line 243: > 241: _g1h(g1h), > 242: _allocation_region(NULL), > 243: _allocated_regions(2, mtGC), Good riddance. src/hotspot/share/memory/allocation.cpp line 154: > 152: > 153: #ifdef ASSERT > 154: thread_local ResourceObj::RecentAllocations ResourceObj::_recent_allocations; Don't use `thread_local`. See the style guide. src/hotspot/share/memory/allocation.cpp line 234: > 232: } > 233: #endif // ASSERT > 234: Keep the blank line after the `#endif` src/hotspot/share/memory/allocation.hpp line 398: > 396: class ResourceObj ALLOCATION_SUPER_CLASS_SPEC { > 397: public: > 398: enum allocation_type : uint8_t { STACK_OR_EMBEDDED, RESOURCE_AREA, C_HEAP, ARENA }; Consider adding an "empty" allocation-type, that indicates an entry in the RecentAllocations is unused. src/hotspot/share/memory/allocation.hpp line 414: > 412: // allocation is done in a recursive step. In that case an assert will trigger. > 413: class RecentAllocations { > 414: static const unsigned BufferSize = 5; "5" seems like an odd choice. src/hotspot/share/memory/allocation.hpp line 416: > 414: static const unsigned BufferSize = 5; > 415: uintptr_t _begin[BufferSize]; > 416: uintptr_t _past_end[BufferSize]; I think these should be `const void*` rather than `uintptr_t`. src/hotspot/share/memory/memRegion.hpp line 110: > 108: // A ResourceObj version of MemRegionClosure > 109: > 110: class MemRegionClosureRO: public ResourceObj { I think this class could be deleted entirely, with the only derived class (`DirtyCardToOopClosure`) instead deriving from ResourceObj. src/hotspot/share/prims/jvmtiDeferredUpdates.hpp line 132: > 130: JvmtiDeferredUpdates() : > 131: _relock_count_after_wait(0), > 132: _deferred_locals_updates(1, mtCompiler) { } Good riddance. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From rrich at openjdk.java.net Thu Oct 7 08:24:15 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 7 Oct 2021 08:24:15 GMT Subject: Integrated: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 13:44:44 GMT, Richard Reingruber wrote: > The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed as many times as necessary for them to run. > > It should be changed to > > All threads suspended by the thread-level **suspend** command or the VM-level > **suspend** command are resumed as many times as necessary for them to run. > > [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) This pull request has now been integrated. Changeset: 29dcbb72 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/29dcbb72a2d9b224203d92ad3224cf149a7d08de Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. Reviewed-by: alanb, cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5804 From rrich at openjdk.java.net Thu Oct 7 08:24:14 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 7 Oct 2021 08:24:14 GMT Subject: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2] In-Reply-To: References: Message-ID: <8A_QrLoJmA_4geXNGdSXDGPih87WJK-MLDtWjHulr74=.0ca7e57a-ea66-4f94-a8f0-a41a682fe79c@github.com> On Tue, 5 Oct 2021 07:38:28 GMT, Richard Reingruber wrote: >> The following sentence in the JDWP Specification describing the Dispose command confuses resume with suspend [1]: >> >> All threads suspended by the thread-level **resume** command or the VM-level >> **resume** command are resumed as many times as necessary for them to run. >> >> It should be changed to >> >> All threads suspended by the thread-level **suspend** command or the VM-level >> **suspend** command are resumed as many times as necessary for them to run. >> >> [1] [JDWP Spec, Dispose Command (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/5804 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 09:41:21 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 09:41:21 GMT Subject: Integrated: 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 21:35:41 GMT, Andrey Turbanov wrote: > There are few places in code where manual while loop is used with Iterator to iterate over Collection. > Instead of manual while cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. > It doesn't have any performance impact: java compiler generates similar code when compiling enhanced-for cycle. > > Similar cleanups: > * https://bugs.openjdk.java.net/browse/JDK-8258006 > * https://bugs.openjdk.java.net/browse/JDK-8257912 This pull request has now been integrated. Changeset: d5ccfa2a Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/d5ccfa2ae965a9ae0f3597b0b90d702a3e0ea558 Stats: 81 lines in 9 files changed: 0 ins; 35 del; 46 mod 8274755: Replace 'while' cycles with iterator with enhanced-for in jdk.jdi Reviewed-by: alanb, amenkov, sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5577 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 11:41:25 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 11:41:25 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules Message-ID: StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance ------------- Commit messages: - [PATCH] Cleanup usages of StringBuffer in jdk tools modules Changes: https://git.openjdk.java.net/jdk/pull/5433/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5433&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274898 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5433/head:pull/5433 PR: https://git.openjdk.java.net/jdk/pull/5433 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 11:47:20 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 11:47:20 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Message-ID: Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - 8272992: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/5697/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274899 Stats: 26 lines in 7 files changed: 0 ins; 13 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5697/head:pull/5697 PR: https://git.openjdk.java.net/jdk/pull/5697 From lzang at openjdk.java.net Thu Oct 7 11:57:06 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 7 Oct 2021 11:57:06 GMT Subject: RFR: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: <7TTiEe89ODrVoKS735_T1NQC2WA3XM9EezXEV3rwwuc=.20b0700e-b4c8-456a-8b25-bc17829210cc@github.com> On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field could be sucessfully parsed. > We think this class can be removed for 2 reasons: > 1. The gzip heap dump file generated by `jhsdb` command does not contain the "blocksize" header field, so the GzipRandomAccess can not parse the generated file successfully. > 2. The `GzipInputStream` could be used instead and then gziped heap dump file generated from both `jcmd`/`jmap` and `jhsdb jmap` could be parsed using same logic. > Options Thanks all for your help reviewed this PR, I will push it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From lzang at openjdk.java.net Thu Oct 7 12:00:15 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 7 Oct 2021 12:00:15 GMT Subject: Integrated: 8273929: Remove GzipRandomAccess in heap dump test In-Reply-To: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> References: <1L_MCfxOj5TNuwUPk-zygaYhIbi1aN74D12Kq0xrD5k=.3abba5ef-1f59-41a3-beb6-0c7cd3abe85a@github.com> Message-ID: On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote: > The class `GzipRandomAccess` is used to parse heap dump file generated from `jcmd`/`jmap` tools when testing. > It has the limitation that only gzip file which has "blocksize" header field could be sucessfully parsed. > We think this class can be removed for 2 reasons: > 1. The gzip heap dump file generated by `jhsdb` command does not contain the "blocksize" header field, so the GzipRandomAccess can not parse the generated file successfully. > 2. The `GzipInputStream` could be used instead and then gziped heap dump file generated from both `jcmd`/`jmap` and `jhsdb jmap` could be parsed using same logic. > Options This pull request has now been integrated. Changeset: 340c715c Author: Lin Zang URL: https://git.openjdk.java.net/jdk/commit/340c715c3b0f5ad5204f9dddb17a787b07426543 Stats: 578 lines in 2 files changed: 0 ins; 578 del; 0 mod 8273929: Remove GzipRandomAccess in heap dump test Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5556 From coleenp at openjdk.java.net Thu Oct 7 12:29:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 12:29:10 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. test/hotspot/gtest/runtime/test_mutex.cpp line 290: > 288: ThreadInVMfromNative invm(THREAD); > 289: > 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); @dholmes-ora This test checks for overlapping safepoint ranges. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Thu Oct 7 12:38:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 12:38:09 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <4dtM1iipmdLApuuovC-NqC6ejIpsqdn3r69uRdr6POY=.49a782a0-3c52-45dc-9710-55c09dc2bb58@github.com> On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. test/hotspot/gtest/runtime/test_mutex.cpp line 327: > 325: // If the lock above succeeds, try to safepoint to test the NSV implied with this nosafepoint lock. > 326: ThreadBlockInVM tbivm(thread); > 327: thread->print_thread_state_on(tty); I moved the three tests from test_safepoint.cpp here. The third test in that file was checking the specification of _safepoint_check_always/never matched the rank, which is now obsolete. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From shade at openjdk.java.net Thu Oct 7 12:51:32 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Oct 2021 12:51:32 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace Message-ID: This is a Zero infrastructure improvement that makes Zero VM work with AsyncGetCallTrace, and by extension, async-profiler. Zero is quite odd in stack management. The "real" stack actually contains the C++ Interpreter and the rest of VM code. The Java stack is reported through the usual "frame" mechanism the rest of VM uses to get the mapping from Template Interpreter, stub, and compiled code. So, to support Java-centric AsyncGetCallTrace, we t "only" need Zero to report the proper Java frames from its ZeroStack from the profiling/signal handlers. Additional testing: - [x] Linux x86_64 Zero `serviceability/AsyncGetCallTrace` now pass - [x] Linux x86_64 Zero works with `async-profiler` ------------- Commit messages: - Initial work: runs async-profiler successfully Changes: https://git.openjdk.java.net/jdk/pull/5848/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274903 Stats: 136 lines in 4 files changed: 124 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5848.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5848/head:pull/5848 PR: https://git.openjdk.java.net/jdk/pull/5848 From denghui.ddh at alibaba-inc.com Thu Oct 7 13:58:27 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 07 Oct 2021 21:58:27 +0800 Subject: =?UTF-8?B?RXh0ZW5kIGpjbWQgdG8gamF2YSBhcHBsaWNhdGlvbiBsZXZlbA==?= Message-ID: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> Hi team, The `jcmd` command can be used to call some built-in diagnostic commands in vm. Can we consider extending it to the java layer like perf data, so that Java developers can customize their diagnostic commands and then call them through `jcmd`? One application scenario I can think of for this extension is that some statistical information may be collected in a java application. Triggering the output of this statistical information through the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through an HTTP service, or periodic Printing) is more convenient. Any input is appreciated. Thanks, Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrich at openjdk.java.net Thu Oct 7 14:20:26 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 7 Oct 2021 14:20:26 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Message-ID: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> This change fixes deadlocks described in the JBS-bug by: * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` * Notifying on `threadLock` in `threadControl_reset()` Also the actions in handleAppResumeBreakpoint() are moved/deferred until doPendingTasks() runs. This is necessary because an event handler must not release handlerLock first and foremost because handlers are called while iterating the handler chain for an event type which is protected by handlerLock (see https://github.com/openjdk/jdk/pull/5805) The first commit delays the cleanup actions after leaving the loop in `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 test with the command make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 The second commit adds a new test that reproduces the deadlock when calling threadControl_resumeThread() while a thread is waiting in blockOnDebuggerSuspend(). The third commit contains the fix described above. With it the deadlocks cannot be reproduced anymore. The forth commit removes the diagnostic code introduced with the first commit again. The fix passed test/hotspot/jtreg/serviceability/jdwp test/jdk/com/sun/jdi test/hotspot/jtreg/vmTestbase/nsk/jdwp test/hotspot/jtreg/vmTestbase/nsk/jdi ------------- Commit messages: - Remove delay in cleanup again. - Fix that prevents deadlocks. - New test that deadlocks target VM calling ThreadReference.resume(). - Delay cleanup after JDWP Dispose command to trigger deadlock in the test dispose003 Changes: https://git.openjdk.java.net/jdk/pull/5849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274687 Stats: 280 lines in 2 files changed: 262 ins; 13 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From sspitsyn at openjdk.java.net Thu Oct 7 15:23:09 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 15:23:09 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From coleenp at openjdk.java.net Thu Oct 7 15:28:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 15:28:31 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix overlap error message printing and add a test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5845/files - new: https://git.openjdk.java.net/jdk/pull/5845/files/3c6a5b6c..59bfd945 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=00-01 Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From sspitsyn at openjdk.java.net Thu Oct 7 15:29:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 15:29:08 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey, Nice simplification. It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5697 From cjplummer at openjdk.java.net Thu Oct 7 15:54:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Oct 2021 15:54:09 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From pchilanomate at openjdk.java.net Thu Oct 7 16:02:08 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 7 Oct 2021 16:02:08 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. LGTM! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Thu Oct 7 16:10:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 16:10:08 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:59:42 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix overlap error message printing and add a test. > > LGTM! > > Thanks, > Patricio Thanks for the review @pchilano and offline discussion about check_for_overlap. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From ccheung at openjdk.java.net Thu Oct 7 20:33:12 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 7 Oct 2021 20:33:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8] In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 21:53:30 GMT, Yumin Qi wrote: >> Please review, >> Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. >> With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. >> >> Tests: tier1-4 >> jtreg on sa. >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Add offset check for _generic_header in populate_header I just have one minor comment. It's up to you if you want to change it. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java line 58: > 56: static void runTwo(String base, String top, > 57: String jarName, String mainClassName, int exitValue, > 58: String ... checkMessages) throws Exception { I don't think this method is necessary since the existing run2() method seems to do the same thing. The only advantage I see is the call site is less verbose than before. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Thu Oct 7 21:13:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 7 Oct 2021 21:13:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 20:30:00 GMT, Calvin Cheung wrote: > I just have one minor comment. It's up to you if you want to change it. Thanks for review --- I will leave as it is now. ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Thu Oct 7 21:36:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 7 Oct 2021 21:36:12 GMT Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 06:06:02 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add offset check for _generic_header in populate_header > > LGTM @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From minqi at openjdk.java.net Thu Oct 7 21:36:13 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 7 Oct 2021 21:36:13 GMT Subject: Integrated: 8273152: Refactor CDS FileMapHeader loading code In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 05:43:40 GMT, Yumin Qi wrote: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. > With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check. > > Tests: tier1-4 > jtreg on sa. > > Thanks > Yumin This pull request has now been integrated. Changeset: 8de77634 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/8de77634c414cc348a6eb7b28fd6339befdb12d7 Stats: 566 lines in 11 files changed: 333 ins; 100 del; 133 mod 8273152: Refactor CDS FileMapHeader loading code Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/5768 From amenkov at openjdk.java.net Thu Oct 7 21:53:27 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 7 Oct 2021 21:53:27 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Message-ID: The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) ------------- Commit messages: - JDK-8274930 Changes: https://git.openjdk.java.net/jdk/pull/5858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274930 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5858/head:pull/5858 PR: https://git.openjdk.java.net/jdk/pull/5858 From sspitsyn at openjdk.java.net Thu Oct 7 22:43:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 22:43:08 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) LGTM. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5858 From suenaga at oss.nttdata.com Thu Oct 7 23:45:52 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 8 Oct 2021 08:45:52 +0900 Subject: Extend jcmd to java application level In-Reply-To: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> Message-ID: <859822cf-79cc-c980-1339-9ef8247efa98@oss.nttdata.com> Hi Denghui, I think you can do it with combination of JVMTI.data_dump dcmd and DataDumpRequest event in JVMTI. JVM(TM) Tool Interface 17.0.0 (oracle.com) Thanks, Yasumasa On 2021/10/07 22:58, Denghui Dong wrote: > Hi team, > > The `jcmd` command can be used to call some built-in diagnostic commands in vm. > Can we consider extending it to the java layer like perf data, so that Java developers can > customize their diagnostic commands and then call them through `jcmd`? > > One application scenario I can think of for this extension is that some statistical information > may be collected in a java application. Triggering the output of this statistical information through > the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through > an HTTP service, or periodic Printing) is more convenient. > > Any input is appreciated. > > Thanks, > Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.java.net Fri Oct 8 00:56:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Oct 2021 00:56:18 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. Hi Coleen, A couple of comments on tests, but otherwise okay. Thanks, David test/hotspot/gtest/runtime/test_mutex.cpp line 292: > 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); > 291: monitor_rank_broken->lock_without_safepoint_check(); > 292: monitor_rank_broken->unlock(); This is dead code right - the assertion failure will stop us getting here. test/hotspot/gtest/runtime/test_mutex.cpp line 302: > 300: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-40, "monitor_rank_broken"); > 301: monitor_rank_broken->lock_without_safepoint_check(); > 302: monitor_rank_broken->unlock(); Ditto - dead code test/hotspot/gtest/runtime/test_mutex.cpp line 310: > 308: ThreadInVMfromNative invm(THREAD); > 309: > 310: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-1, "monitor_rank_broken"); This rank is not actually broken is it - otherwise we won't get to the next line. test/hotspot/gtest/runtime/test_mutex.cpp line 313: > 311: Monitor* monitor_rank_also_broken = new Monitor(monitor_rank_broken->rank()-39, "monitor_rank_also_broken"); > 312: monitor_rank_also_broken->lock_without_safepoint_check(); > 313: monitor_rank_also_broken->unlock(); Dead code ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5845 From denghui.ddh at alibaba-inc.com Fri Oct 8 01:09:08 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 08 Oct 2021 09:09:08 +0800 Subject: =?UTF-8?B?UmU6IEV4dGVuZCBqY21kIHRvIGphdmEgYXBwbGljYXRpb24gbGV2ZWw=?= In-Reply-To: <859822cf-79cc-c980-1339-9ef8247efa98@oss.nttdata.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com>, <859822cf-79cc-c980-1339-9ef8247efa98@oss.nttdata.com> Message-ID: Hi Yasumasa, JVMTI.data_dump and DataDumpRequest can achieve the purpose of triggering. IIUC, DataDumpRequest does not seem to be able to pass parameters. And sometimes the action the user wants to trigger may not be a data dump. In fact, I think that commands such as JFR.start/stop are such a mechanism, triggered by `jcmd`, and finally callback to the java layer. Denghui Dong ------------------------------------------------------------------ From:Yasumasa Suenaga Send Time:2021?10?8?(???) 07:45 To:???(??) ; serviceability-dev ; hotspot-runtime-dev at openjdk.java.net Subject:Re: Extend jcmd to java application level Hi Denghui, I think you can do it with combination of JVMTI.data_dump dcmd and DataDumpRequest event in JVMTI. JVM(TM) Tool Interface 17.0.0 (oracle.com) Thanks, Yasumasa On 2021/10/07 22:58, Denghui Dong wrote: Hi team, The `jcmd` command can be used to call some built-in diagnostic commands in vm. Can we consider extending it to the java layer like perf data, so that Java developers can customize their diagnostic commands and then call them through `jcmd`? One application scenario I can think of for this extension is that some statistical information may be collected in a java application. Triggering the output of this statistical information through the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through an HTTP service, or periodic Printing) is more convenient. Any input is appreciated. Thanks, Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Oct 8 01:25:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Oct 2021 11:25:18 +1000 Subject: Extend jcmd to java application level In-Reply-To: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> Message-ID: <8633cbbd-e6f3-db67-ecad-ee7d4dfb5868@oracle.com> Hi Denghui, On 7/10/2021 11:58 pm, Denghui Dong wrote: > Hi?team, > > The?`jcmd`?command?can?be?used?to?call?some?built-in?diagnostic?commands?in?vm. > Can?we?consider?extending?it?to?the?java?layer?like?perf?data,?so?that?Java?developers?can > customize?their?diagnostic?commands?and?then?call?them?through?`jcmd`? > > One?application?scenario?I?can?think?of?for?this?extension?is?that?some?statistical?information > may?be?collected?in?a?java?application.?Triggering?the?output?of?this?statistical?information?through > the?`jcmd`?command?seems?to?me?relative?to?other?mechanisms?that?trigger?output?(such?as?through > an?HTTP?service,?or?periodic?Printing)?is?more?convenient. > > Any?input?is?appreciated. If the intent is that you could issue a jcmd: jcmd MyClass.foo to have it run/use a Java thread to execute arbitrary code then I think a lot of careful consideration would need to be given to making this facility safe and secure. I can easily imagine that the thread used, and the timing, could cause failures. Executing arbitrary code may be far too general, so it might mean we need a new "service" interface defined that the target class has to implement. It might well be useful but will need some deep thought IMO. Cheers, David > Thanks, > Denghui?Dong From suenaga at oss.nttdata.com Fri Oct 8 01:29:50 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 8 Oct 2021 10:29:50 +0900 Subject: Extend jcmd to java application level In-Reply-To: References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> <859822cf-79cc-c980-1339-9ef8247efa98@oss.nttdata.com> Message-ID: Hi Denghui, I thought to add JMX client feature to jcmd in the past for similar purposes, but I didn't because JMX URL is too complex to type into console :) Your proposal is useful, but it means malicious users can inject arbitrary code. I think we need to consider security, and existing framework like JMX might help us. Thanks, Yasumasa On 2021/10/08 10:09, Denghui Dong wrote: > Hi Yasumasa, > > JVMTI.data_dump?and?DataDumpRequest?can?achieve?the?purpose?of?triggering. > > IIUC, DataDumpRequest?does?not?seem?to?be?able?to pass parameters. > And?sometimes?the?action?the?user?wants?to?trigger?may?not?be?a?data?dump. > > In?fact,?I?think?that?commands?such?as?JFR.start/stop?are?such?a?mechanism,?triggered?by `jcmd`,?and?finally?callback?to?the?java?layer. > > Denghui Dong > > ------------------------------------------------------------------ > From:Yasumasa Suenaga > Send Time:2021?10?8?(???) 07:45 > To:???(??) ; serviceability-dev ; hotspot-runtime-dev at openjdk.java.net > Subject:Re: Extend jcmd to java application level > > Hi Denghui, > > > I think you can do it with combination of JVMTI.data_dump dcmd and DataDumpRequest event in JVMTI. > > JVM(TM) Tool Interface 17.0.0 (oracle.com) > > > Thanks, > > Yasumasa > > > On 2021/10/07 22:58, Denghui Dong wrote: > > Hi team, > > The `jcmd` command can be used to call some built-in diagnostic commands in vm. > Can we consider extending it to the java layer like perf data, so that Java developers can > customize their diagnostic commands and then call them through `jcmd`? > > One application scenario I can think of for this extension is that some statistical information > may be collected in a java application. Triggering the output of this statistical information through > the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through > an HTTP service, or periodic Printing) is more convenient. > > Any input is appreciated. > > Thanks, > Denghui Dong > > From lzang at openjdk.java.net Fri Oct 8 06:09:18 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 8 Oct 2021 06:09:18 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out Message-ID: This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) The root cause is that `BufferedOutputStream` should be used when writting data to file. ------------- Commit messages: - Undo problem list of the test case - 8274620: TestHeapDumpForLargeArray.java is timing out Changes: https://git.openjdk.java.net/jdk/pull/5860/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5860&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274620 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5860/head:pull/5860 PR: https://git.openjdk.java.net/jdk/pull/5860 From ioi.lam at oracle.com Fri Oct 8 07:22:29 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 8 Oct 2021 00:22:29 -0700 Subject: Extend jcmd to java application level In-Reply-To: <8633cbbd-e6f3-db67-ecad-ee7d4dfb5868@oracle.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> <8633cbbd-e6f3-db67-ecad-ee7d4dfb5868@oracle.com> Message-ID: On 10/7/21 6:25 PM, David Holmes wrote: > Hi Denghui, > > On 7/10/2021 11:58 pm, Denghui Dong wrote: >> Hi?team, >> >> The?`jcmd`?command?can?be?used?to?call?some?built-in?diagnostic?commands?in?vm. >> >> Can?we?consider?extending?it?to?the?java?layer?like?perf?data,?so?that?Java?developers?can >> >> customize?their?diagnostic?commands?and?then?call?them?through?`jcmd`? >> >> One?application?scenario?I?can?think?of?for?this?extension?is?that?some?statistical?information >> >> may?be?collected?in?a?java?application.?Triggering?the?output?of?this?statistical?information?through >> >> the?`jcmd`?command?seems?to?me?relative?to?other?mechanisms?that?trigger?output?(such?as?through >> >> an?HTTP?service,?or?periodic?Printing)?is?more?convenient. >> >> Any?input?is?appreciated. > > If the intent is that you could issue a jcmd: > > jcmd MyClass.foo > > to have it run/use a Java thread to execute arbitrary code then I > think a lot of careful consideration would need to be given to making > this facility safe and secure. I can easily imagine that the thread > used, and the timing, could cause failures. Executing arbitrary code > may be far too general, so it might mean we need a new "service" > interface defined that the target class has to implement. > > It might well be useful but will need some deep thought IMO. > If I understood correctly, the app would need to call an API like: ??? JcmdProvider.register("mycmd1", new JcmdHandler() { ?????? public void handleCommand(String args[], PrintStream out) { ?????????? out.print("my response is "); ? ? ? ... } ??? }); and then the user can issue: ??? jcmd mycmd1 args ..... which will reach the handleCommand() method provided by the app. Thanks - Ioi > Cheers, > David > >> Thanks, >> Denghui?Dong From qingfeng.yy at alibaba-inc.com Fri Oct 8 07:44:47 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Fri, 08 Oct 2021 15:44:47 +0800 Subject: =?UTF-8?B?UmU6IEV4dGVuZCBqY21kIHRvIGphdmEgYXBwbGljYXRpb24gbGV2ZWw=?= In-Reply-To: References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> <8633cbbd-e6f3-db67-ecad-ee7d4dfb5868@oracle.com>, Message-ID: <65861ca9-d6b3-443e-9889-5b5dec7793a2.qingfeng.yy@alibaba-inc.com> That seems an ideal solution. I think there are some potential code consolidation work further. With this change, some existing C++ JFR Jcmd structure definitions(and other Jcmd commands) in VM level can also be lifted to Java level because they simply forward request to Java level by JavaCalls::call_static. ------------------------------------------------------------------ From:Ioi Lam Send Time:2021 Oct. 8 (Fri.) 15:22 To:David Holmes ; dong denghui ; serviceability-dev ; hotspot-runtime-dev at openjdk.java.net Subject:Re: Extend jcmd to java application level On 10/7/21 6:25 PM, David Holmes wrote: > Hi Denghui, > > On 7/10/2021 11:58 pm, Denghui Dong wrote: >> Hi team, >> >> The `jcmd` command can be used to call some built-in diagnostic commands in vm. >> >> Can we consider extending it to the java layer like perf data, so that Java developers can >> >> customize their diagnostic commands and then call them through `jcmd`? >> >> One application scenario I can think of for this extension is that some statistical information >> >> may be collected in a java application. Triggering the output of this statistical information through >> >> the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through >> >> an HTTP service, or periodic Printing) is more convenient. >> >> Any input is appreciated. > > If the intent is that you could issue a jcmd: > > jcmd MyClass.foo > > to have it run/use a Java thread to execute arbitrary code then I > think a lot of careful consideration would need to be given to making > this facility safe and secure. I can easily imagine that the thread > used, and the timing, could cause failures. Executing arbitrary code > may be far too general, so it might mean we need a new "service" > interface defined that the target class has to implement. > > It might well be useful but will need some deep thought IMO. > If I understood correctly, the app would need to call an API like: JcmdProvider.register("mycmd1", new JcmdHandler() { public void handleCommand(String args[], PrintStream out) { out.print("my response is "); ... } }); and then the user can issue: jcmd mycmd1 args ..... which will reach the handleCommand() method provided by the app. Thanks - Ioi > Cheers, > David > >> Thanks, >> Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Fri Oct 8 08:47:48 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 8 Oct 2021 08:47:48 +0000 Subject: Extend jcmd to java application level In-Reply-To: <65861ca9-d6b3-443e-9889-5b5dec7793a2.qingfeng.yy@alibaba-inc.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> <8633cbbd-e6f3-db67-ecad-ee7d4dfb5868@oracle.com> <65861ca9-d6b3-443e-9889-5b5dec7793a2.qingfeng.yy@alibaba-inc.com> Message-ID: To make an application command usable, it must provide metadata (name and description of the command, its options? data types, units, default values, if it is mandatory etc.) and error handling. This will make the API surface larger and trickier to get right. (Not a full overlap, but we are thinking of adding more interactive capabilities to JFR now that we have event streaming. The design hasn?t started, but one could imagine a command to see object allocation events aggregated in a histogram. Such a command may be able to operate on user-defined events as well, including requestable/periodic events.) Erik That seems an ideal solution. I think there are some potential code consolidation work further. With this change, some existing C++ JFR Jcmd structure definitions(and other Jcmd commands) in VM level can also be lifted to Java level because they simply forward request to Java level by JavaCalls::call_static. ------------------------------------------------------------------ From:Ioi Lam Send Time:2021 Oct. 8 (Fri.) 15:22 To:David Holmes ; dong denghui ; serviceability-dev ; hotspot-runtime-dev at openjdk.java.net Subject:Re: Extend jcmd to java application level On 10/7/21 6:25 PM, David Holmes wrote: > Hi Denghui, > > On 7/10/2021 11:58 pm, Denghui Dong wrote: >> Hi team, >> >> The `jcmd` command can be used to call some built-in diagnostic commands in vm. >> >> Can we consider extending it to the java layer like perf data, so that Java developers can >> >> customize their diagnostic commands and then call them through `jcmd`? >> >> One application scenario I can think of for this extension is that some statistical information >> >> may be collected in a java application. Triggering the output of this statistical information through >> >> the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through >> >> an HTTP service, or periodic Printing) is more convenient. >> >> Any input is appreciated. > > If the intent is that you could issue a jcmd: > > jcmd MyClass.foo > > to have it run/use a Java thread to execute arbitrary code then I > think a lot of careful consideration would need to be given to making > this facility safe and secure. I can easily imagine that the thread > used, and the timing, could cause failures. Executing arbitrary code > may be far too general, so it might mean we need a new "service" > interface defined that the target class has to implement. > > It might well be useful but will need some deep thought IMO. > If I understood correctly, the app would need to call an API like: JcmdProvider.register("mycmd1", new JcmdHandler() { public void handleCommand(String args[], PrintStream out) { out.print("my response is "); ... } }); and then the user can issue: jcmd mycmd1 args ..... which will reach the handleCommand() method provided by the app. Thanks - Ioi > Cheers, > David > >> Thanks, >> Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.java.net Fri Oct 8 12:26:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:46 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. I removed the dead test code and retested. Thanks for the code review David, and all the discussions leading to this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:42 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v3] In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <_j_8HU0x6wY_wdykmr-yK3m3Vh9xe_8EBHAndUvqaTI=.6868eeb9-8087-45bd-8aea-06ed9cda720f@github.com> > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove dead code in test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5845/files - new: https://git.openjdk.java.net/jdk/pull/5845/files/59bfd945..e8df15de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:55 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <6D3k_Hszkk1_wh4hVsg_SN-KjzC-qtLzz7y7KY8oy_c=.7c9d92e6-0564-45b5-84fa-d3750f218626@github.com> On Fri, 8 Oct 2021 00:48:05 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix overlap error message printing and add a test. > > test/hotspot/gtest/runtime/test_mutex.cpp line 292: > >> 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); >> 291: monitor_rank_broken->lock_without_safepoint_check(); >> 292: monitor_rank_broken->unlock(); > > This is dead code right - the assertion failure will stop us getting here. Yes, it is dead code. I'll remove it and retest to make sure nothing surprising happens. > test/hotspot/gtest/runtime/test_mutex.cpp line 302: > >> 300: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-40, "monitor_rank_broken"); >> 301: monitor_rank_broken->lock_without_safepoint_check(); >> 302: monitor_rank_broken->unlock(); > > Ditto - dead code removed. > test/hotspot/gtest/runtime/test_mutex.cpp line 310: > >> 308: ThreadInVMfromNative invm(THREAD); >> 309: >> 310: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-1, "monitor_rank_broken"); > > This rank is not actually broken is it - otherwise we won't get to the next line. right. It's not broken. I'll rename it to 'monitor_rank_ok'. > test/hotspot/gtest/runtime/test_mutex.cpp line 313: > >> 311: Monitor* monitor_rank_also_broken = new Monitor(monitor_rank_broken->rank()-39, "monitor_rank_also_broken"); >> 312: monitor_rank_also_broken->lock_without_safepoint_check(); >> 313: monitor_rank_also_broken->unlock(); > > Dead code removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:57 GMT Subject: Integrated: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <0lCdhQcwqr2iY7jits8rmozKtqgOpJ1f4NAWCRoWQIc=.8d3c7b24-6629-4743-bd4c-537198df641d@github.com> On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. This pull request has now been integrated. Changeset: 6364719c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/6364719cd1c57220769ea580d958da8dc2fdf7f9 Stats: 452 lines in 41 files changed: 105 ins; 117 del; 230 mod 8274004: Change 'nonleaf' rank name 8273956: Add checking for rank values Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From github.com+10835776+stsypanov at openjdk.java.net Fri Oct 8 19:42:07 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 8 Oct 2021 19:42:07 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117: > 115: > 116: for (String s : strings) { > 117: sb.append(" " + s); Shouldn't it be `sb.append(" ").append(s)`? ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From cjplummer at openjdk.java.net Fri Oct 8 21:08:14 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 8 Oct 2021 21:08:14 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 06:00:03 GMT, Lin Zang wrote: > This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) > The root cause is that `BufferedOutputStream` should be used when writting data to file. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From lzang at openjdk.java.net Sat Oct 9 00:48:06 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Sat, 9 Oct 2021 00:48:06 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: <9VlIiFQfBDBoZMV0ISt7Ba_8FrKCjtRClF7teTffaO0=.73208fa2-b169-49bd-a59f-cef2e99f6eb5@github.com> On Fri, 8 Oct 2021 21:05:16 GMT, Chris Plummer wrote: >> This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) >> The root cause is that `BufferedOutputStream` should be used when writting data to file. > > Marked as reviewed by cjplummer (Reviewer). Dear @plummercj, Thanks a lot for your quick review, since this is a trivial patch, do you think it needs one more approval before push? BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From cjplummer at openjdk.java.net Sat Oct 9 03:41:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 9 Oct 2021 03:41:09 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 21:05:16 GMT, Chris Plummer wrote: >> This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) >> The root cause is that `BufferedOutputStream` should be used when writting data to file. > > Marked as reviewed by cjplummer (Reviewer). > Dear @plummercj, Thanks a lot for your quick review, since this is a trivial patch, do you think it needs one more approval before push? I'd prefer that it got a second review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From denghui.ddh at alibaba-inc.com Sat Oct 9 06:14:44 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 09 Oct 2021 14:14:44 +0800 Subject: =?UTF-8?B?UmU6IEV4dGVuZCBqY21kIHRvIGphdmEgYXBwbGljYXRpb24gbGV2ZWw=?= In-Reply-To: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> References: <0270e817-488e-41dc-b6a5-91427fba8cc2.denghui.ddh@alibaba-inc.com> Message-ID: Hi, Thank you for the response. I just made a PoC for this extension: https://github.com/D-D-H/jdk/commit/eb2a13b7ba8bd3e6d048491c8a579b179d2cef0d Here is the test code: ``` import sun.management.cmd.CmdMeta; import sun.management.cmd.Command; import sun.management.cmd.ParamMeta; import sun.management.cmd.Factory; import java.io.PrintWriter; public class Test { public static void main(String... args) throws Exception { Factory.register(Echo.class); Thread.sleep(60000); } } @CmdMeta(name = "My.Echo") class Echo implements Command { public Echo() {} @ParamMeta(name = "text", isMandatory = true) String text; @Override public void execute(PrintWriter out) { out.println(text); } } ``` Verify steps: 1. javac --add-exports java.management/sun.management.cmd=ALL-UNNAMED Test.java 1. java --add-exports java.management/sun.management.cmd=ALL-UNNAMED Test 3. jcmd My.Echo text=message At present, it is only the most basic implementation, mainly referring to the implementation of dmcd in the VM layer. and there are many places that need more careful design and implementation, such as security and timeout If you think this extension is useful, I'm happy to continue this work. Thanks, Denghui ------------------------------------------------------------------ From:???(??) Send Time:2021?10?7?(???) 21:58 To:serviceability-dev ; hotspot-runtime-dev at openjdk.java.net Subject:Extend jcmd to java application level Hi team, The `jcmd` command can be used to call some built-in diagnostic commands in vm. Can we consider extending it to the java layer like perf data, so that Java developers can customize their diagnostic commands and then call them through `jcmd`? One application scenario I can think of for this extension is that some statistical information may be collected in a java application. Triggering the output of this statistical information through the `jcmd` command seems to me relative to other mechanisms that trigger output (such as through an HTTP service, or periodic Printing) is more convenient. Any input is appreciated. Thanks, Denghui Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzang at openjdk.java.net Sat Oct 9 10:10:07 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Sat, 9 Oct 2021 10:10:07 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 03:38:20 GMT, Chris Plummer wrote: >> Marked as reviewed by cjplummer (Reviewer). > >> Dear @plummercj, Thanks a lot for your quick review, since this is a trivial patch, do you think it needs one more approval before push? > I'd prefer that it got a second review. @plummercj Thanks! Dear All, May I ask your help to review this simple fix? Thanks. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From dholmes at openjdk.java.net Mon Oct 11 00:41:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Oct 2021 00:41:06 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 06:00:03 GMT, Lin Zang wrote: > This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) > The root cause is that `BufferedOutputStream` should be used when writting data to file. LGTM. This code should be rewritten to use try-with-resources at some point. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5860 From lzang at openjdk.java.net Mon Oct 11 02:00:14 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 02:00:14 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 00:38:22 GMT, David Holmes wrote: >> This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) >> The root cause is that `BufferedOutputStream` should be used when writting data to file. > > LGTM. > > This code should be rewritten to use try-with-resources at some point. > > Thanks, > David Thanks @dholmes-ora for review and comments! I will create another issue in JBS for the try-with-resources change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From lzang at openjdk.java.net Mon Oct 11 02:00:14 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 02:00:14 GMT Subject: Integrated: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 06:00:03 GMT, Lin Zang wrote: > This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) > The root cause is that `BufferedOutputStream` should be used when writting data to file. This pull request has now been integrated. Changeset: 5ecc99bb Author: Lin Zang URL: https://git.openjdk.java.net/jdk/commit/5ecc99bbf55e631b5bfa07e2c36b38e820682363 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From dholmes at openjdk.java.net Mon Oct 11 04:20:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Oct 2021 04:20:10 GMT Subject: RFR: 8274620: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 06:00:03 GMT, Lin Zang wrote: > This PR fix the issue of JDK-8274620 (resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java is timing out) > The root cause is that `BufferedOutputStream` should be used when writting data to file. Looks like this change to use a buffered stream is now causing serviceability/sa/TestJmapCore.java to fail with "Stackframe 0x4 not found" - which I'm going to assume is due to the buffering and a missing flush/close. I am filing a bug for that and will assign to you. David ------------- PR: https://git.openjdk.java.net/jdk/pull/5860 From lzang at openjdk.java.net Mon Oct 11 10:30:36 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 10:30:36 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found Message-ID: The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. ------------- Commit messages: - 8275021: Test serviceability/sa/TestJmapCore.java fails Changes: https://git.openjdk.java.net/jdk/pull/5890/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5890&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275021 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5890.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5890/head:pull/5890 PR: https://git.openjdk.java.net/jdk/pull/5890 From dholmes at openjdk.java.net Mon Oct 11 12:20:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Oct 2021 12:20:09 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 10:25:01 GMT, Lin Zang wrote: > The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. Fix seems good. Suggestion on the comment. Thanks, David src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 619: > 617: out.writeInt(0); > 618: // remember position of dump length, we will fixup > 619: // length later - hprof format require length. The comment is not very clear to me. I suggest per your description, to simply say: // We must flush all data to the file before reading the current file position. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5890 From pliden at openjdk.java.net Mon Oct 11 12:33:42 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 11 Oct 2021 12:33:42 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure Message-ID: I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: * Rename AbstractGangTask to WorkerTask * Rename WorkGang to WorkerThreads * Fold GangWorker into WorkerThread * Fold WorkManager into WorkerThreads * Move SubTaskDone and friends to a new workerUtils.hpp/cpp I've split things up into several commits to make it easier to review. Testing: Passes Tier 1-3 on all Oracle platforms. ------------- Commit messages: - Clean up naming in ReferenceProcessor - Clean up naming in Shenandoah - Clean up naming in HeapDumper/HeapInspector - Clean up naming in G1 - Clean up naming in pretouch - Clean up naming in WeakProcessor - Clean up naming in ZGC - Remove unused log tag - Rename workgroup.hpp/cpp to workerThread.hpp/cpp - Clean up worker code - ... and 10 more: https://git.openjdk.java.net/jdk/compare/c032186b...39b23f42 Changes: https://git.openjdk.java.net/jdk/pull/5886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275035 Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/5886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5886/head:pull/5886 PR: https://git.openjdk.java.net/jdk/pull/5886 From lzang at openjdk.java.net Mon Oct 11 12:40:31 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 12:40:31 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: > The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. Lin Zang has updated the pull request incrementally with one additional commit since the last revision: refine comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5890/files - new: https://git.openjdk.java.net/jdk/pull/5890/files/17da4f52..93e9ab77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5890&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5890&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5890.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5890/head:pull/5890 PR: https://git.openjdk.java.net/jdk/pull/5890 From lzang at openjdk.java.net Mon Oct 11 12:40:32 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 12:40:32 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:17:04 GMT, David Holmes wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> refine comments > > Fix seems good. Suggestion on the comment. > > Thanks, > David Hi David @dholmes-ora, Thanks a lot for your quick review! Do you think this PR need a second review before push? BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/5890 From stefank at openjdk.java.net Mon Oct 11 12:46:09 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 11 Oct 2021 12:46:09 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Looks good ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5886 From dcubed at openjdk.java.net Mon Oct 11 14:37:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 14:37:11 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:40:31 GMT, Lin Zang wrote: >> The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > refine comments Thumbs up. Were you able to reproduce the test failure and have you verified that this fix does cause the test to pass? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5890 From lzang at openjdk.java.net Mon Oct 11 14:41:10 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 14:41:10 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: <4NP_Bmi3bHBQPBSaNnhSN63E4c8QX8Q60Y3_pPSj9Jg=.6ec76c28-d6d3-4b01-a4a8-5e081c46bfae@github.com> On Mon, 11 Oct 2021 14:34:28 GMT, Daniel D. Daugherty wrote: > Thumbs up. > > Were you able to reproduce the test failure and have you verified that this fix does cause the test to pass? Yes? I can reproduce the fail on my MacOS box, and this patch can make it pass sucessfully. ------------- PR: https://git.openjdk.java.net/jdk/pull/5890 From dcubed at openjdk.java.net Mon Oct 11 14:49:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 14:49:10 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:40:31 GMT, Lin Zang wrote: >> The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > refine comments Thanks for confirmation. This is a trivial fix and does not have to wait for 24 hours. ------------- PR: https://git.openjdk.java.net/jdk/pull/5890 From lzang at openjdk.java.net Mon Oct 11 15:03:08 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 15:03:08 GMT Subject: RFR: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 14:46:15 GMT, Daniel D. Daugherty wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> refine comments > > Thanks for confirmation. This is a trivial fix and does not have > to wait for 24 hours. Dear Daniel (@dcubed-ojdk), Thanks for your help reviewing, I am still dong some tests on my MacOS box for double check, I will push this change when it finish. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/5890 From lzang at openjdk.java.net Mon Oct 11 15:31:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 11 Oct 2021 15:31:12 GMT Subject: Integrated: 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 10:25:01 GMT, Lin Zang wrote: > The root cause for the fail is that there must be a flush for `BufferedOutputStream` before getting the `pos` of the file, otherwise the data length is wrongly calculated. This pull request has now been integrated. Changeset: 3f01d03a Author: Lin Zang URL: https://git.openjdk.java.net/jdk/commit/3f01d03a10cb3f647735ed4bbea1768ff18bf8f2 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8275021: Test serviceability/sa/TestJmapCore.java fails with: java.io.IOException: Stack frame 0x4 not found Reviewed-by: dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/5890 From duke at openjdk.java.net Mon Oct 11 19:02:09 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Oct 2021 19:02:09 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 06:53:13 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From duke at openjdk.java.net Mon Oct 11 19:02:18 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 19:02:18 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com> On Fri, 8 Oct 2021 19:38:57 GMT, ?????? ??????? wrote: >> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117: > >> 115: >> 116: for (String s : strings) { >> 117: sb.append(" " + s); > > Shouldn't it be `sb.append(" ").append(s)`? I will do under a separate issue and PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From duke at openjdk.java.net Mon Oct 11 19:02:20 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Oct 2021 19:02:20 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com> References: <92uut52ZoNSElCDbL-0JcebbUyJSpnzEvNGPmY8ITuM=.bc9093e9-9f37-4fb4-bb26-bcb0eb6497f8@github.com> Message-ID: On Mon, 11 Oct 2021 18:52:13 GMT, Andrey Turbanov wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java line 117: >> >>> 115: >>> 116: for (String s : strings) { >>> 117: sb.append(" " + s); >> >> Shouldn't it be `sb.append(" ").append(s)`? > > I will do under a separate issue and PR. Cool! ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From duke at openjdk.java.net Mon Oct 11 19:02:34 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Oct 2021 19:02:34 GMT Subject: RFR: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent Message-ID: Cleanup unnecessary toString() calls when conversion will happen implicitly anyway ------------- Commit messages: - [PATCH] Remove unnecessary conversion to String in jdk.hotspot.agent module Changes: https://git.openjdk.java.net/jdk/pull/5800/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5800&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275075 Stats: 14 lines in 4 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5800.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5800/head:pull/5800 PR: https://git.openjdk.java.net/jdk/pull/5800 From sspitsyn at openjdk.java.net Mon Oct 11 21:38:49 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 11 Oct 2021 21:38:49 GMT Subject: RFR: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 18:58:50 GMT, Andrey Turbanov wrote: > Cleanup unnecessary toString() calls when conversion will happen implicitly anyway Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5800 From dcubed at openjdk.java.net Mon Oct 11 22:19:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 22:19:59 GMT Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v5] In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: <57TIrfbf94gkCEFOM0NIlVMNYmVLz8fs1iWps-lxsOQ=.a4bc4e9d-03a9-4db4-8715-4fb37220384b@github.com> > A trivial fix to support JFR use of new ThreadsList::Iterator. > > This fix was tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into JDK-8271514 - Merge branch 'master' into JDK-8271514 - Merge branch 'master' into JDK-8271514 - Merge branch 'pull/4948' into JDK-8271514 - Merge branch 'master' into JDK-8271513 - Merge branch 'pull/4948' into JDK-8271514 - Merge branch 'pull/4671' into JDK-8271513 - kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' - 8271514: support JFR use of new ThreadsList::Iterator - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator - ... and 4 more: https://git.openjdk.java.net/jdk/compare/829dea45...a2e39c36 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4949/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4949&range=04 Stats: 39 lines in 2 files changed: 20 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4949/head:pull/4949 PR: https://git.openjdk.java.net/jdk/pull/4949 From dcubed at openjdk.java.net Mon Oct 11 22:20:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 22:20:01 GMT Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v4] In-Reply-To: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Wed, 22 Sep 2021 03:56:25 GMT, Daniel D. Daugherty wrote: >> A trivial fix to support JFR use of new ThreadsList::Iterator. >> >> This fix was tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into JDK-8271514 > - Merge branch 'master' into JDK-8271514 > - Merge branch 'pull/4948' into JDK-8271514 > - Merge branch 'master' into JDK-8271513 > - Merge branch 'pull/4948' into JDK-8271514 > - Merge branch 'pull/4671' into JDK-8271513 > - kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' > - 8271514: support JFR use of new ThreadsList::Iterator > - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator > - 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features. > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cbe57e86...76d44dcb Rebased this project to the latest jdk/jdk baseline as of 2021.10.11 in the afternoon. This PR needs a review from either @mgronlun or @egahlin since I'm changing JFR code here. The rebase has passed Mach5 Tier1 testing; Mach5 Tier[23] are in process. ------------- PR: https://git.openjdk.java.net/jdk/pull/4949 From dcubed at openjdk.java.net Mon Oct 11 22:21:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 22:21:29 GMT Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes [v5] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: > A trivial fix to reduce ThreadListHandle overhead in relation to handshakes. > > This refactoring was tested with Mach5 Tier[1-3]. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8249004 - Merge branch 'master' into JDK-8249004 - Merge branch 'master' into JDK-8249004 - Merge branch 'master' into JDK-8249004 - Merge branch 'master' into JDK-8249004 - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/093ad308..a214b284 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=03-04 Stats: 29064 lines in 862 files changed: 18659 ins; 5895 del; 4510 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Mon Oct 11 22:21:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Oct 2021 22:21:36 GMT Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes [v4] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: <9cjz4F_AR0Kcd4FBuAlpodrJS3Mc2zvZjhubywWBJhY=.f773f399-d4eb-4b66-b184-7fcf743034c9@github.com> On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty wrote: >> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes. >> >> This refactoring was tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into JDK-8249004 > - Merge branch 'master' into JDK-8249004 > - Merge branch 'master' into JDK-8249004 > - Merge branch 'master' into JDK-8249004 > - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes Rebased this project to the latest jdk/jdk baseline as of 2021.10.11 in the afternoon. HOWEVER, I'm still working on the latest version of the fix so please do not review this PR yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dholmes at openjdk.java.net Tue Oct 12 02:12:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Oct 2021 02:12:48 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Changes to non GC files look fine. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From cjplummer at openjdk.java.net Tue Oct 12 05:50:46 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 12 Oct 2021 05:50:46 GMT Subject: RFR: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 18:58:50 GMT, Andrey Turbanov wrote: > Cleanup unnecessary toString() calls when conversion will happen implicitly anyway Marked as reviewed by cjplummer (Reviewer). src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java line 1012: > 1010: tmpBuf.append(Long.toHexString(startPc + visitor.getInstructionSize())); > 1011: tmpBuf.append(",0x"); > 1012: tmpBuf.append(Long.toHexString(startPc)); Overall these changes look good, although I do wonder what motivated to `toString()` calls in the first place, especially this example where lines 1010 and 1012 are similar, but only 1010 used `toString()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5800 From cjplummer at openjdk.java.net Tue Oct 12 06:02:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 12 Oct 2021 06:02:47 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: <76HbkIDYdxcRzy8xZ1oNZaaDZfMe8kMAqH8iowJ3_qQ=.03721118-9f5a-457e-aeaa-404ee10632e7@github.com> On Thu, 7 Oct 2021 13:50:49 GMT, Richard Reingruber wrote: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 31: > 29: * the JDWP agent (in blockOnDebuggerSuspend()) because it called > 30: * j.l.Thread.resume() on a thread R that was suspended by the > 31: * debugger. This is hard to follow. Maybe instead document the steps the test takes. For example maybe something like: Suspend Thread R via breakpoint. Thread T calls j.l.Thread.resume() on Thread R, resulting in Thread T blocking in blockOnDebuggerSuspend. Resume Thread R using ThreadReference.resume(). Verify that Thread T is no longer blocked in blockOnDebuggerSuspend. Also, it would be nice if thread names in the description matched the names used in the implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From serb at openjdk.java.net Tue Oct 12 07:10:48 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 12 Oct 2021 07:10:48 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4] In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 12:19:53 GMT, ?????? ??????? wrote: >> In some JDK classes there's still the following hashCode() implementation: >> >> long objNum; >> >> public int hashCode() { >> return (int) objNum; >> } >> >> This outdated expression should be replaced with Long.hashCode(long) as it >> >> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). >> >> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. >> >> See https://stackoverflow.com/a/4045083 >> >> This is related to https://github.com/openjdk/jdk/pull/4309 > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268764: Update copy-right year Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From rrich at openjdk.java.net Tue Oct 12 07:47:15 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 12 Oct 2021 07:47:15 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v2] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve @summary section of test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/8c1b5cec..6cc006b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=00-01 Stats: 30 lines in 1 file changed: 18 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Tue Oct 12 07:51:22 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 12 Oct 2021 07:51:22 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v3] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve @summary section of test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/6cc006b1..e198e5ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Tue Oct 12 08:03:22 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 12 Oct 2021 08:03:22 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve @summary section of test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/e198e5ea..8c51e71f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Tue Oct 12 08:03:25 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 12 Oct 2021 08:03:25 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <76HbkIDYdxcRzy8xZ1oNZaaDZfMe8kMAqH8iowJ3_qQ=.03721118-9f5a-457e-aeaa-404ee10632e7@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <76HbkIDYdxcRzy8xZ1oNZaaDZfMe8kMAqH8iowJ3_qQ=.03721118-9f5a-457e-aeaa-404ee10632e7@github.com> Message-ID: On Tue, 12 Oct 2021 05:59:28 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 31: > >> 29: * the JDWP agent (in blockOnDebuggerSuspend()) because it called >> 30: * j.l.Thread.resume() on a thread R that was suspended by the >> 31: * debugger. > > This is hard to follow. Maybe instead document the steps the test takes. For example maybe something like: Suspend Thread R via breakpoint. Thread T calls j.l.Thread.resume() on Thread R, resulting in Thread T blocking in blockOnDebuggerSuspend. Resume Thread R using ThreadReference.resume(). Verify that Thread T is no longer blocked in blockOnDebuggerSuspend. > > Also, it would be nice if thread names in the description matched the names used in the implementation. Thanks for looking at this. I've updated the test summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From mgronlun at openjdk.java.net Tue Oct 12 11:27:55 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Oct 2021 11:27:55 GMT Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v5] In-Reply-To: <57TIrfbf94gkCEFOM0NIlVMNYmVLz8fs1iWps-lxsOQ=.a4bc4e9d-03a9-4db4-8715-4fb37220384b@github.com> References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> <57TIrfbf94gkCEFOM0NIlVMNYmVLz8fs1iWps-lxsOQ=.a4bc4e9d-03a9-4db4-8715-4fb37220384b@github.com> Message-ID: On Mon, 11 Oct 2021 22:19:59 GMT, Daniel D. Daugherty wrote: >> A trivial fix to support JFR use of new ThreadsList::Iterator. >> >> This fix was tested with Mach5 Tier[1-3]. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into JDK-8271514 > - Merge branch 'master' into JDK-8271514 > - Merge branch 'master' into JDK-8271514 > - Merge branch 'pull/4948' into JDK-8271514 > - Merge branch 'master' into JDK-8271513 > - Merge branch 'pull/4948' into JDK-8271514 > - Merge branch 'pull/4671' into JDK-8271513 > - kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)' > - 8271514: support JFR use of new ThreadsList::Iterator > - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/829dea45...a2e39c36 Looks good Dan, thank you. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4949 From prappo at openjdk.java.net Tue Oct 12 16:22:58 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 12 Oct 2021 16:22:58 GMT Subject: RFR: 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules [v4] In-Reply-To: References: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com> Message-ID: On Sat, 25 Sep 2021 11:23:18 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. >> Affected modules: jdk.javadoc, jdk.jcmd, jdk.jconsole > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules > extracted jdk.hotspot.agent changes into separate PR. Rollback them here. Changes to the jdk.javadoc module look good; I can sponsor this PR. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5230 From prappo at openjdk.java.net Tue Oct 12 16:37:49 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 12 Oct 2021 16:37:49 GMT Subject: RFR: 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules [v4] In-Reply-To: References: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com> Message-ID: On Sat, 25 Sep 2021 11:23:18 GMT, Andrey Turbanov wrote: >> Collections.sort is just a wrapper, so it is better to use an instance method directly. >> Affected modules: jdk.javadoc, jdk.jcmd, jdk.jconsole > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules > extracted jdk.hotspot.agent changes into separate PR. Rollback them here. I've submitted an extended test job with the 5f75485 commit; if that job shows no issues, I'll sponsor this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5230 From dcubed at openjdk.java.net Tue Oct 12 17:08:54 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 12 Oct 2021 17:08:54 GMT Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v2] In-Reply-To: References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Wed, 4 Aug 2021 22:57:40 GMT, Serguei Spitsyn wrote: >> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'pull/4948' into JDK-8271514 >> - Merge branch 'pull/4948' into JDK-8271514 >> - 8271514: support JFR use of new ThreadsList::Iterator > > Hi Dan, > It looks good to me modulo the question from David. > Thanks, > Serguei @sspitsyn and @mgronlun - Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/4949 From dcubed at openjdk.java.net Tue Oct 12 17:08:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 12 Oct 2021 17:08:55 GMT Subject: Integrated: 8271514: support JFR use of new ThreadsList::Iterator In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com> Message-ID: On Fri, 30 Jul 2021 20:20:48 GMT, Daniel D. Daugherty wrote: > A trivial fix to support JFR use of new ThreadsList::Iterator. > > This fix was tested with Mach5 Tier[1-3]. This pull request has now been integrated. Changeset: 8657f776 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/8657f77608f37d7ff5254032858f2f16c7c204d5 Stats: 39 lines in 2 files changed: 20 ins; 11 del; 8 mod 8271514: support JFR use of new ThreadsList::Iterator Co-authored-by: Kim Barrett Reviewed-by: sspitsyn, mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/4949 From duke at openjdk.java.net Tue Oct 12 19:16:52 2021 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 12 Oct 2021 19:16:52 GMT Subject: Integrated: 8268764: Use Long.hashCode() instead of int-cast where applicable In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 12:15:11 GMT, ?????? ??????? wrote: > In some JDK classes there's still the following hashCode() implementation: > > long objNum; > > public int hashCode() { > return (int) objNum; > } > > This outdated expression should be replaced with Long.hashCode(long) as it > > - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). > > - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. > > See https://stackoverflow.com/a/4045083 > > This is related to https://github.com/openjdk/jdk/pull/4309 This pull request has now been integrated. Changeset: 124f8237 Author: Sergey Tsypanov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/124f82377ba93359bc59118ee315ba194080fa92 Stats: 21 lines in 9 files changed: 6 ins; 0 del; 15 mod 8268764: Use Long.hashCode() instead of int-cast where applicable Reviewed-by: kevinw, prr, kizune, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4491 From duke at openjdk.java.net Tue Oct 12 20:57:53 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Oct 2021 20:57:53 GMT Subject: RFR: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 05:37:53 GMT, Chris Plummer wrote: >> Cleanup unnecessary toString() calls when conversion will happen implicitly anyway > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java line 1012: > >> 1010: tmpBuf.append(Long.toHexString(startPc + visitor.getInstructionSize())); >> 1011: tmpBuf.append(",0x"); >> 1012: tmpBuf.append(Long.toHexString(startPc)); > > Overall these changes look good, although I do wonder what motivated to `toString()` calls in the first place, especially this example where lines 1010 and 1012 are similar, but only 1010 used `toString()`. Often reason for such mistakes is pretty trivial: copy-paste error, refactoring stopped in the middle or incorrect merge. Unfortunately this code is from pre-OpenJDK and it's impossible to find original motifaction. ------------- PR: https://git.openjdk.java.net/jdk/pull/5800 From iklam at openjdk.java.net Wed Oct 13 04:28:15 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 13 Oct 2021 04:28:15 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager Message-ID: LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. - Remove all APIs that take a user name - Also removed PerfDataFile.getFile() methods that are unused - Cleaned up the code that looks up the hsperfdata_xxx files - Fix comments to explain what's happening - Avoid using Matcher.reset which is not thread-safe - Renamed confusing variables such as `userFilter` to make the code more readable - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). ------------- Commit messages: - 8275185: Remove dead code and clean up jvmstat LocalVmManager Changes: https://git.openjdk.java.net/jdk/pull/5923/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5923&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275185 Stats: 319 lines in 2 files changed: 9 ins; 278 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5923.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5923/head:pull/5923 PR: https://git.openjdk.java.net/jdk/pull/5923 From cjplummer at openjdk.java.net Wed Oct 13 06:47:51 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Oct 2021 06:47:51 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> Message-ID: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> On Tue, 12 Oct 2021 08:03:22 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the actions in handleAppResumeBreakpoint() are moved/deferred until >> doPendingTasks() runs. This is necessary because an event handler must not >> release handlerLock first and foremost because handlers are called while >> iterating the handler chain for an event type which is protected by handlerLock >> (see https://github.com/openjdk/jdk/pull/5805) >> >> The first commit delays the cleanup actions after leaving the loop in >> `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 >> test with the command >> >> >> make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 >> >> >> The second commit adds a new test that reproduces the deadlock when calling >> threadControl_resumeThread() while a thread is waiting in >> blockOnDebuggerSuspend(). >> >> The third commit contains the fix described above. With it the deadlocks >> cannot be reproduced anymore. >> >> The forth commit removes the diagnostic code introduced with the first commit again. >> >> The fix passed >> >> test/hotspot/jtreg/serviceability/jdwp >> test/jdk/com/sun/jdi >> test/hotspot/jtreg/vmTestbase/nsk/jdwp >> test/hotspot/jtreg/vmTestbase/nsk/jdi > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve @summary section of test. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2200: > 2198: /* trackAppResume() needs handlerLock */ > 2199: debugMonitorExit(threadLock); > 2200: eventHandler_lock(); /* for proper lock order */ Is it still necessary for the handlerLock to be held when calling `blockOnDebuggerSuspend()` (presuming you don't also add the new handlerLock related code in it)? It seems that only the threadLock is needed so it can then wait on it. The main thing you've done to fix this issue is defer the `blockOnDebuggerSuspend()` to be done after `event_callback()` has released the handlerLock, and to make it so `blockOnDebuggerSuspend()` does not block while holding the handlerLock, so is there really any reason to be grabbing it at all? src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2220: > 2218: * suspends a thread it will remain suspended. > 2219: */ > 2220: trackAppResume(resumer); `trackAppResume()` doesn't really need the handlerLock. However, it will grab it when calling `eventHandler_createInternalThreadOnly()`. Since you want to make sure it is grabbed before threadLock in order to preserve lock ordering, that complicates things if we decided not to grab the handlerLock in the code above. What I'm now thinking is all that is really needed is to hold the threadLock around the call to `blockOnDebuggerSuspend()`, or better yet just grab it from within `blockOnDebuggerSuspend()`. You probably don't need to do anything with handlerLock or threadLock inside of `doPendingTasks()`. test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 81: > 79: System.out.println(); > 80: System.out.println("###(Target,"+ threadName +") " + m); > 81: System.out.println(); I'm not sure why you have the two extra `println()` calls. Seems to just add unneeded blank lines in the log file. test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 100: > 98: // "resumee" is suspended now because of the breakpoint > 99: // Calling Thread.resume() will block this thread. > 100: no need for empty line here test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 159: > 157: ThreadReference resumee = bpe.thread(); > 158: ObjectReference resumeeThreadObj = resumee.frame(1).thisObject(); > 159: printStack(resumee); As long as you're printing stacks, I think the stack of the main thread would be useful here, but you need to suspend it first. I don't think that interferes with the test. ``` mainThread.suspend(); printStack(mainThread); mainThread.resume(); test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 165: > 163: setField(resumeeThreadObj, "reachedBreakpoint", vm().mirrorOf(true)); > 164: > 165: log("Sleeping 500ms shows that the main thread is blocked calling Thread.resume() on \"resumee\" Thread."); "shows" -> "so" test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 167: > 165: log("Sleeping 500ms shows that the main thread is blocked calling Thread.resume() on \"resumee\" Thread."); > 166: Thread.sleep(500); > 167: log("After sleep."); And after line 167 is also a good place to print the main thread's stack. test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 176: > 174: mainThreadReturnedFromResumeCall = ((PrimitiveValue) v).booleanValue(); > 175: if (!resumedResumee) { > 176: // main thread should be still blocked. "...should still be blocked" test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 222: > 220: System.out.println(); > 221: System.out.println("###(Debugger) " + m); > 222: System.out.println(); Same here with the extra `printlin()` calls ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From cjplummer at openjdk.java.net Wed Oct 13 07:08:55 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Oct 2021 07:08:55 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> Message-ID: On Tue, 12 Oct 2021 08:03:22 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the actions in handleAppResumeBreakpoint() are moved/deferred until >> doPendingTasks() runs. This is necessary because an event handler must not >> release handlerLock first and foremost because handlers are called while >> iterating the handler chain for an event type which is protected by handlerLock >> (see https://github.com/openjdk/jdk/pull/5805) >> >> The first commit delays the cleanup actions after leaving the loop in >> `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 >> test with the command >> >> >> make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 >> >> >> The second commit adds a new test that reproduces the deadlock when calling >> threadControl_resumeThread() while a thread is waiting in >> blockOnDebuggerSuspend(). >> >> The third commit contains the fix described above. With it the deadlocks >> cannot be reproduced anymore. >> >> The forth commit removes the diagnostic code introduced with the first commit again. >> >> The fix passed >> >> test/hotspot/jtreg/serviceability/jdwp >> test/jdk/com/sun/jdi >> test/hotspot/jtreg/vmTestbase/nsk/jdwp >> test/hotspot/jtreg/vmTestbase/nsk/jdi > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve @summary section of test. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750: > 748: * handlerLock and threadLock are owned when returning and the suspendCount of > 749: * the given thread is 0. > 750: */ How about: /* * The caller must own handlerLock and threadLock. * If the suspendCount of the given thread is greater than 0, then the * current thread will release the handlerLock and wait on the threadLock. It * must release the handlerLock first, because threadControl_resumeThread() * and threadControl_resumeAll() need it, and calling them is how suspendCount * will eventually be decremented to 0. * handlerLock and threadLock are owned when returning and the suspendCount of * the given thread is 0. */ ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From duke at openjdk.java.net Wed Oct 13 09:09:51 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 09:09:51 GMT Subject: Integrated: 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sun, 3 Oct 2021 18:58:50 GMT, Andrey Turbanov wrote: > Cleanup unnecessary toString() calls when conversion will happen implicitly anyway This pull request has now been integrated. Changeset: dcf428c7 Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/dcf428c7a74e568deaededfc11d3c4e1bf7821f2 Stats: 14 lines in 4 files changed: 0 ins; 1 del; 13 mod 8275075: Remove unnecessary conversion to String in jdk.hotspot.agent Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5800 From rrich at openjdk.java.net Wed Oct 13 09:34:02 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 09:34:02 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: <8m1Z3-nD8LWcOErUGux92XjF5FUi0AY7KwRpanCCS-E=.d084eae1-afca-460f-96c2-b0ea3ce1b6a3@github.com> On Tue, 12 Oct 2021 21:06:00 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 81: > >> 79: System.out.println(); >> 80: System.out.println("###(Target,"+ threadName +") " + m); >> 81: System.out.println(); > > I'm not sure why you have the two extra `println()` calls. Seems to just add unneeded blank lines in the log file. I'll remove them. I think I copied the method from another test where I used a lot of jit compiler tracing. > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 222: > >> 220: System.out.println(); >> 221: System.out.println("###(Debugger) " + m); >> 222: System.out.println(); > > Same here with the extra `printlin()` calls I'll remove them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 13 09:38:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 09:38:49 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Tue, 12 Oct 2021 21:35:59 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 165: > >> 163: setField(resumeeThreadObj, "reachedBreakpoint", vm().mirrorOf(true)); >> 164: >> 165: log("Sleeping 500ms shows that the main thread is blocked calling Thread.resume() on \"resumee\" Thread."); > > "shows" -> "so" Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 13 10:04:50 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 10:04:50 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Tue, 12 Oct 2021 21:39:35 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 159: > >> 157: ThreadReference resumee = bpe.thread(); >> 158: ObjectReference resumeeThreadObj = resumee.frame(1).thisObject(); >> 159: printStack(resumee); > > As long as you're printing stacks, I think the stack of the main thread would be useful here, but you need to suspend it first. I don't think that interferes with the test. > ``` > mainThread.suspend(); > printStack(mainThread); > mainThread.resume(); I've added that. > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 167: > >> 165: log("Sleeping 500ms shows that the main thread is blocked calling Thread.resume() on \"resumee\" Thread."); >> 166: Thread.sleep(500); >> 167: log("After sleep."); > > And after line 167 is also a good place to print the main thread's stack. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From duke at openjdk.java.net Wed Oct 13 11:37:57 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 11:37:57 GMT Subject: Integrated: 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules In-Reply-To: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com> References: <9xbhI0rwD3XbAHZFfQAkJHYivbC5F4N085RuSVWx8HU=.8a470c93-5fee-4981-97e4-afb6cb1147b9@github.com> Message-ID: On Mon, 23 Aug 2021 21:08:05 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. > Affected modules: jdk.javadoc, jdk.jcmd, jdk.jconsole This pull request has now been integrated. Changeset: 5ffb5d10 Author: Andrey Turbanov Committer: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/5ffb5d100f3383f9afaf20c8a659971522153505 Stats: 14 lines in 5 files changed: 0 ins; 3 del; 11 mod 8272992: Replace usages of Collections.sort with List.sort call in jdk.* modules Reviewed-by: cjplummer, prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/5230 From rrich at openjdk.java.net Wed Oct 13 12:16:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 12:16:49 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: <9vsOgS8nh2uqOxHCQHJFtuXBb_fTPpyQksfzI5uTea0=.80270cf1-a1fa-487f-88ec-f6d93012c215@github.com> On Tue, 12 Oct 2021 21:45:03 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 100: > >> 98: // "resumee" is suspended now because of the breakpoint >> 99: // Calling Thread.resume() will block this thread. >> 100: > > no need for empty line here Done. > test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 176: > >> 174: mainThreadReturnedFromResumeCall = ((PrimitiveValue) v).booleanValue(); >> 175: if (!resumedResumee) { >> 176: // main thread should be still blocked. > > "...should still be blocked" Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 13 13:05:51 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 13:05:51 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> Message-ID: On Wed, 13 Oct 2021 07:06:17 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750: > >> 748: * handlerLock and threadLock are owned when returning and the suspendCount of >> 749: * the given thread is 0. >> 750: */ > > How about: > > /* > * The caller must own handlerLock and threadLock. > * If the suspendCount of the given thread is greater than 0, then the > * current thread will release the handlerLock and wait on the threadLock. It > * must release the handlerLock first, because threadControl_resumeThread() > * and threadControl_resumeAll() need it, and calling them is how suspendCount > * will eventually be decremented to 0. > * handlerLock and threadLock are owned when returning and the suspendCount of > * the given thread is 0. > */ Reads better. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 13 13:29:51 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 13:29:51 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Tue, 12 Oct 2021 22:55:05 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve @summary section of test. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2200: > >> 2198: /* trackAppResume() needs handlerLock */ >> 2199: debugMonitorExit(threadLock); >> 2200: eventHandler_lock(); /* for proper lock order */ > > Is it still necessary for the handlerLock to be held when calling `blockOnDebuggerSuspend()` (presuming you don't also add the new handlerLock related code in it)? It seems that only the threadLock is needed so it can then wait on it. > > The main thing you've done to fix this issue is defer the `blockOnDebuggerSuspend()` to be done after `event_callback()` has released the handlerLock, and to make it so `blockOnDebuggerSuspend()` does not block while holding the handlerLock, so is there really any reason to be grabbing it at all? Please see my answer on your [comment for L2220](https://github.com/openjdk/jdk/pull/5849#discussion_r727573811) > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2220: > >> 2218: * suspends a thread it will remain suspended. >> 2219: */ >> 2220: trackAppResume(resumer); > > `trackAppResume()` doesn't really need the handlerLock. However, it will grab it when calling `eventHandler_createInternalThreadOnly()`. Since you want to make sure it is grabbed before threadLock in order to preserve lock ordering, that complicates things if we decided not to grab the handlerLock in the code above. What I'm now thinking is all that is really needed is to hold the threadLock around the call to `blockOnDebuggerSuspend()`, or better yet just grab it from within `blockOnDebuggerSuspend()`. You probably don't need to do anything with handlerLock or threadLock inside of `doPendingTasks()`. After returning from `blockOnDebuggerSuspend()` we have to make sure resumee cannot be suspended by JDWP means otherwise the current thread which is about to execute j.l.Thread.resume() will interfere with the debugger. This is achieved by holding threadLock until the tracking is established by `trackAppResume()`. For symmetry the set of owned locks should be equal before/after calling `blockOnDebuggerSuspend()` I think. Therefore handlerLock and threadLock are acquired before. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 13 13:45:23 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 13 Oct 2021 13:45:23 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v5] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: <4_eHe4gdT_wNAalWrMTtnOkufF-EOzD-B1z1ycELnMI=.6109fdae-8e6a-4dbe-9c0d-59d54bb59843@github.com> > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: - Adding source filename and line numbers to printStack(). - Changes based on plummercj's comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/8c51e71f..806bceb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=03-04 Stats: 24 lines in 2 files changed: 12 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From ayang at openjdk.java.net Wed Oct 13 14:57:52 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Oct 2021 14:57:52 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: <0_2hNibwTQ_O4ogxshpot8dy46d3J9NkHQ2CCP4TMIo=.3f95825d-1aa9-44e6-b068-50c7515102a9@github.com> On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From mgronlun at openjdk.java.net Wed Oct 13 17:49:18 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 17:49:18 GMT Subject: RFR: 8266936: Add a finalization JFR event [v15] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch '8266936-alt' of github.com:mgronlun/jdk into 8266936-alt - symbols-unix - jvm.h and JVM_Entry - no precompiled headers and mtServiceability nmt classification - remove rehashing and rely on default grow_hint for table resize - mtStatistics - localize - cleanup - FinalizerStatistics - Model as finalizerService - ... and 34 more: https://git.openjdk.java.net/jdk/compare/124f8237...5359a793 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14 Stats: 1893 lines in 36 files changed: 1375 ins; 409 del; 109 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 From mgronlun at openjdk.java.net Wed Oct 13 18:03:25 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Oct 2021 18:03:25 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - cleanup - rebased and adjusted for new lock rankings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/5359a793..96a9d6bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=14-15 Stats: 0 lines in 0 files changed: 0 ins; 0 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 From duke at openjdk.java.net Wed Oct 13 18:42:05 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Oct 2021 18:42:05 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which in many cases can be avoided. Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) ------------- Commit messages: - [PATCH] Change nested classes in jdk.attach to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/5904/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5904&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275240 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5904/head:pull/5904 PR: https://git.openjdk.java.net/jdk/pull/5904 From darcy at openjdk.java.net Wed Oct 13 20:07:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 20:07:14 GMT Subject: RFR: JDK-8275244: Suppress warnings on non-serializable array component types in jdk.management Message-ID: After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. >From "Java Object Serialization Specification: 2 - Object Output Classes": "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." The jdk.management module has an instance of this coding pattern that need suppression to compile successfully under the future warning. ------------- Commit messages: - JDK-8275244: Suppress warnings on non-serializable array component types in jdk.management Changes: https://git.openjdk.java.net/jdk/pull/5934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5934&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275244 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5934/head:pull/5934 PR: https://git.openjdk.java.net/jdk/pull/5934 From alanb at openjdk.java.net Wed Oct 13 20:11:48 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Oct 2021 20:11:48 GMT Subject: RFR: JDK-8275244: Suppress warnings on non-serializable array component types in jdk.management In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 19:58:43 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The jdk.management module has an instance of this coding pattern that need suppression to compile successfully under the future warning. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5934 From darcy at openjdk.java.net Wed Oct 13 20:21:56 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 13 Oct 2021 20:21:56 GMT Subject: Integrated: JDK-8275244: Suppress warnings on non-serializable array component types in jdk.management In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 19:58:43 GMT, Joe Darcy wrote: > After a refinement to the checks under development in #5709, the new checks examine array types of serial fields and warn if the underlying component type is not serializable. Per the JLS, all array types are serializable, but if the base component is not serializable, the serialization process can throw an exception. > > From "Java Object Serialization Specification: 2 - Object Output Classes": > > "If the object is an array, writeObject is called recursively to write the ObjectStreamClass of the array. The handle for the array is assigned. It is followed by the length of the array. Each element of the array is then written to the stream, after which writeObject returns." > > The jdk.management module has an instance of this coding pattern that need suppression to compile successfully under the future warning. This pull request has now been integrated. Changeset: d9e03e42 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d9e03e42afbb2e5115b67accfffad4938b8314b1 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8275244: Suppress warnings on non-serializable array component types in jdk.management Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/5934 From cjplummer at openjdk.java.net Wed Oct 13 20:48:53 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Oct 2021 20:48:53 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 07:20:14 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. > Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5904 From cjplummer at openjdk.java.net Wed Oct 13 21:02:51 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Oct 2021 21:02:51 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Wed, 13 Oct 2021 13:24:06 GMT, Richard Reingruber wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2220: >> >>> 2218: * suspends a thread it will remain suspended. >>> 2219: */ >>> 2220: trackAppResume(resumer); >> >> `trackAppResume()` doesn't really need the handlerLock. However, it will grab it when calling `eventHandler_createInternalThreadOnly()`. Since you want to make sure it is grabbed before threadLock in order to preserve lock ordering, that complicates things if we decided not to grab the handlerLock in the code above. What I'm now thinking is all that is really needed is to hold the threadLock around the call to `blockOnDebuggerSuspend()`, or better yet just grab it from within `blockOnDebuggerSuspend()`. You probably don't need to do anything with handlerLock or threadLock inside of `doPendingTasks()`. > > After returning from `blockOnDebuggerSuspend()` we have to make sure resumee > cannot be suspended by JDWP means otherwise the current thread which is about to > execute j.l.Thread.resume() will interfere with the debugger. This is achieved > by holding threadLock until the tracking is established by `trackAppResume()`. > > For symmetry the set of owned locks should be equal before/after calling > `blockOnDebuggerSuspend()` I think. Therefore handlerLock and threadLock are > acquired before. Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` is done waiting on it until after `trackAppResume()` is done, and since `trackAppResume()` needs to grab the handlerLock, and you need to grab the handerLock before the threadLock, you need to jump through some lock grabbing/release hoops. However, you are in fact releasing the threadLock for a short time in `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the resumee to potential suspending after the wait has completed and before `trackAppResume()` has been called? ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From dholmes at openjdk.java.net Wed Oct 13 21:43:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 13 Oct 2021 21:43:44 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 07:20:14 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. > Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) Seems trivially fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5904 From sspitsyn at openjdk.java.net Thu Oct 14 05:08:58 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 14 Oct 2021 05:08:58 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes In-Reply-To: References: Message-ID: <9UKDP3blHLcvGg_hxktgbGwKm7fWgQYu_3R7GKkbXh4=.2037ccf0-1f27-498d-ada0-f5c7f290a495@github.com> On Tue, 12 Oct 2021 07:20:14 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. > Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) A couple of files need a copyright year update. Otherwise, it looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5904 From ddong at openjdk.java.net Thu Oct 14 05:54:16 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 14 Oct 2021 05:54:16 GMT Subject: RFR: 8275259: Add support for Java level DCmd Message-ID: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. At present, I have implemented a preliminary version. In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. - Executable interface User-defined commands need to implement this interface, the interface only contains a simle method: /** * @param output the output when this executable is running */ void execute(PrintWriter output); - Add two annotations (@Command and @Parameter) to describe the command meta info - Use Factory API to register command, the following forms are supported @Command(name = "My.Echo", description = "Echo description") class Echo implements Executable { @Parameter(name = "text", ordinal=0, isMandatory = true) String text; @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") int repeat; @Override public void execute(PrintWriter out) { for (int i = 0 ; i < repeat; i++) { out.println(text); } } } Factory.register(Echo.class); Factory.register("My.Date", output -> { output.println(new Date()); }); - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. Any input is appreciated. Thanks, Denghui ------------- Commit messages: - 8275259: Add support for Java level DCmd Changes: https://git.openjdk.java.net/jdk/pull/5938/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5938&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275259 Stats: 1159 lines in 12 files changed: 1158 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5938/head:pull/5938 PR: https://git.openjdk.java.net/jdk/pull/5938 From dholmes at openjdk.java.net Thu Oct 14 06:19:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 14 Oct 2021 06:19:48 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong wrote: > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) An API that is expected to be used by application code can't go in the unsupported/internal-use-only sun.management namespace. This would have to be a new external facing supported API. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From ddong at openjdk.java.net Thu Oct 14 06:32:50 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 14 Oct 2021 06:32:50 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Thu, 14 Oct 2021 06:17:13 GMT, David Holmes wrote: > > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) > > An API that is expected to be used by application code can't go in the unsupported/internal-use-only sun.management namespace. This would have to be a new external facing supported API. > > Cheers, David Thanks. I consider putting the API into `javax.management.dcmd`. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From david.holmes at oracle.com Thu Oct 14 06:41:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 16:41:24 +1000 Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: <29edfa90-04a3-c8aa-8ac6-45c4a05eae76@oracle.com> On 14/10/2021 4:32 pm, Denghui Dong wrote: > On Thu, 14 Oct 2021 06:17:13 GMT, David Holmes wrote: > >>> In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) >> >> An API that is expected to be used by application code can't go in the unsupported/internal-use-only sun.management namespace. This would have to be a new external facing supported API. >> >> Cheers, David > > Thanks. > I consider putting the API into `javax.management.dcmd`. What do you think? There are very specific rules related to the use of the javax namespace. I'm not sure exactly where this API would need to go. IIUC jcmd doesn't exist at the Java level it is just a tool, so introducing an API to interact with it seems problematic to me. Other folk in serviceability (both VM and JDK sides) will need to weigh in here. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5938 > From duke at openjdk.java.net Thu Oct 14 06:59:12 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Oct 2021 06:59:12 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes [v2] In-Reply-To: References: Message-ID: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. > Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8275240: Change nested classes in jdk.attach to static nested classes update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5904/files - new: https://git.openjdk.java.net/jdk/pull/5904/files/70cb33a9..06fcaa48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5904&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5904&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5904/head:pull/5904 PR: https://git.openjdk.java.net/jdk/pull/5904 From ddong at openjdk.java.net Thu Oct 14 07:14:51 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 14 Oct 2021 07:14:51 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <29edfa90-04a3-c8aa-8ac6-45c4a05eae76@oracle.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> <29edfa90-04a3-c8aa-8ac6-45c4a05eae76@oracle.com> Message-ID: On Thu, 14 Oct 2021 06:43:20 GMT, David Holmes wrote: > I'm not sure exactly where this API would need to go. IIUC jcmd doesn't exist at the Java level it is just a tool, so introducing an API to interact with it seems problematic to me. IMO, `jcmd` is a client of `dcmd`, the user also can use JMX to execute `dcmd`, this means there already are Java APIs interact with `dcmd`. Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From david.holmes at oracle.com Thu Oct 14 07:38:30 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 17:38:30 +1000 Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> <29edfa90-04a3-c8aa-8ac6-45c4a05eae76@oracle.com> Message-ID: On 14/10/2021 5:14 pm, Denghui Dong wrote: > On Thu, 14 Oct 2021 06:43:20 GMT, David Holmes wrote: > >> I'm not sure exactly where this API would need to go. IIUC jcmd doesn't > exist at the Java level it is just a tool, so introducing an API to > interact with it seems problematic to me. > > IMO, `jcmd` is a client of `dcmd`, the user also can use JMX to execute `dcmd`, this means there already are Java APIs interact with `dcmd`. Ah right - so you're really looking at extending the capabilities of the DiagnosticCommandMBean to add a way to register a Java diagnostic command. David > Denghui > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5938 > From rrich at openjdk.java.net Thu Oct 14 07:47:57 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 14 Oct 2021 07:47:57 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Wed, 13 Oct 2021 20:59:44 GMT, Chris Plummer wrote: > Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` is done waiting on it until after `trackAppResume()` is done, and since `trackAppResume()` needs to grab the handlerLock, and you need to grab the handerLock before the threadLock, you need to jump through some lock grabbing/release hoops. That's correct. > However, you are in fact releasing the threadLock for a short time in `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the resumee to potential suspending after the wait has completed and before `trackAppResume()` has been called? That's correct too. I wouldn't see an issue with it though. I think this is even a preexisting condition. The current thread can lose the race grabbing threadLock after it was notified to the debugger trying to suspend again (if there wasn't the deadlock of course) and consequently suspendCount can (again) be greater than 0 right after the wait. In that case we simply retry. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From ddong at openjdk.java.net Thu Oct 14 08:44:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 14 Oct 2021 08:44:46 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: <1wq001w2Qkb7ioRdIPYiwepR_m79AktKL7zgym_j-1M=.0097e6f1-346a-4ccb-99ba-f5f01cf46986@github.com> On Thu, 14 Oct 2021 07:40:20 GMT, David Holmes wrote: > Ah right - so you're really looking at extending the capabilities of the > DiagnosticCommandMBean to add a way to register a Java diagnostic command. Yes, but we could not add registration API to DiagnosticCommandMBean directly. There are already some VM diagnostic commands that depend on Java methods directly, this extension could also bring benefit to this scenario I think. Hope folks from serviceability could take a look at it:) Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From pliden at openjdk.java.net Thu Oct 14 09:03:18 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 09:03:18 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure [v2] In-Reply-To: References: Message-ID: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Per Liden has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge master - Clean up naming in ReferenceProcessor - Clean up naming in Shenandoah - Clean up naming in HeapDumper/HeapInspector - Clean up naming in G1 - Clean up naming in pretouch - Clean up naming in WeakProcessor - Clean up naming in ZGC - Remove unused log tag - Rename workgroup.hpp/cpp to workerThread.hpp/cpp - ... and 11 more: https://git.openjdk.java.net/jdk/compare/8b1b6f9f...9a89f785 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5886&range=01 Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/5886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5886/head:pull/5886 PR: https://git.openjdk.java.net/jdk/pull/5886 From stuefe at openjdk.java.net Thu Oct 14 11:07:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Oct 2021 11:07:49 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong wrote: > I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. > > At present, I have implemented a preliminary version. > > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. > > - Executable interface > Java diagnostic commands need to implement this interface, the interface only contains a simple method: > > /** > * @param output the output when this executable is running > */ > void execute(PrintWriter output); > > > - Add two annotations (@Command and @Parameter) to describe the command meta info > > - Use Factory API to register command, the following forms are supported > > @Command(name = "My.Echo", description = "Echo description") > class Echo implements Executable { > > @Parameter(name = "text", ordinal=0, isMandatory = true) > String text; > > @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") > int repeat; > > @Override > public void execute(PrintWriter out) { > for (int i = 0 ; i < repeat; i++) { > out.println(text); > } > } > } > > Factory.register(Echo.class); > > > > Factory.register("My.Date", output -> { > output.println(new Date()); > }); > > > - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. > > At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). > > In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. > > Any input is appreciated. > > Thanks, > Denghui Hi, Interesting proposal. I have some questions. - Will hanging java user code block the attach listener thread? If yes, how would you solve that? - Will this require changes to the jcmd client, or will this work with any jcmd client, up- and downward the JDK versions? (the nice thing about jcmd is that all the logic resides at the hotspot and I can use any client to talk to any hotspot) Cheers, Thomas P.S. I think it may be worthwhile to discuss this on the serviceability-dev mailing list first. ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From egahlin at openjdk.java.net Thu Oct 14 12:19:49 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 14 Oct 2021 12:19:49 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong wrote: > I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. > > At present, I have implemented a preliminary version. > > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. > > - Executable interface > Java diagnostic commands need to implement this interface, the interface only contains a simple method: > > /** > * @param output the output when this executable is running > */ > void execute(PrintWriter output); > > > - Add two annotations (@Command and @Parameter) to describe the command meta info > > - Use Factory API to register command, the following forms are supported > > @Command(name = "My.Echo", description = "Echo description") > class Echo implements Executable { > > @Parameter(name = "text", ordinal=0, isMandatory = true) > String text; > > @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") > int repeat; > > @Override > public void execute(PrintWriter out) { > for (int i = 0 ; i < repeat; i++) { > out.println(text); > } > } > } > > Factory.register(Echo.class); > > > > Factory.register("My.Date", output -> { > output.println(new Date()); > }); > > > - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. > > At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). > > In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. > > Any input is appreciated. > > Thanks, > Denghui To understand what is needed (namespacing, error handling, safety, lifecycle etc.) and if this is actually useful for Java, I think you need to write 2-3 commands for a few popular frameworks, for example Spring. If we can't come up with 5-10 commands where this functionality would solve real problems users face, it's unlikely somebody will use it. It will just be a maintenance burden in the JDK. Once an API is added, it's hard to remove. The scope of this seem to be JEP level. (JFR is not a valid use case, since we don't want to add a dependency on annotation classes in the jdk.jcmd module). ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From pliden at openjdk.java.net Thu Oct 14 14:08:56 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 14:08:56 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure [v2] In-Reply-To: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> References: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> Message-ID: On Thu, 14 Oct 2021 09:03:18 GMT, Per Liden wrote: >> I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: >> >> * Rename AbstractGangTask to WorkerTask >> * Rename WorkGang to WorkerThreads >> * Fold GangWorker into WorkerThread >> * Fold WorkManager into WorkerThreads >> * Move SubTaskDone and friends to a new workerUtils.hpp/cpp >> >> I've split things up into several commits to make it easier to review. >> >> Testing: Passes Tier 1-3 on all Oracle platforms. > > Per Liden has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge master > - Clean up naming in ReferenceProcessor > - Clean up naming in Shenandoah > - Clean up naming in HeapDumper/HeapInspector > - Clean up naming in G1 > - Clean up naming in pretouch > - Clean up naming in WeakProcessor > - Clean up naming in ZGC > - Remove unused log tag > - Rename workgroup.hpp/cpp to workerThread.hpp/cpp > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/8b1b6f9f...9a89f785 Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From pliden at openjdk.java.net Thu Oct 14 14:08:57 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 14:08:57 GMT Subject: Integrated: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. This pull request has now been integrated. Changeset: 54b88707 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/54b887076612c0eaa410a849178f8ba0c4ed3eeb Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod 8275035: Clean up worker thread infrastructure Reviewed-by: stefank, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From sspitsyn at openjdk.java.net Thu Oct 14 14:53:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 14 Oct 2021 14:53:54 GMT Subject: RFR: 8275240: Change nested classes in jdk.attach to static nested classes [v2] In-Reply-To: References: Message-ID: <6bNojC-2EWdQpnSN4wMiFG9EINHW73MNlEkT4XazORM=.0e21e10f-4af5-4bf5-b84b-f6189c63fefe@github.com> On Thu, 14 Oct 2021 06:59:12 GMT, Andrey Turbanov wrote: >> Non-static classes hold a link to their parent classes, which in many cases can be avoided. >> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8275240: Change nested classes in jdk.attach to static nested classes > update copyright year Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5904 From dcubed at openjdk.java.net Thu Oct 14 16:03:28 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Oct 2021 16:03:28 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> > A fix to reduce ThreadsListHandle overhead in relation to handshakes and > we add sanity checks for ThreadsListHandles higher in the call stack. > > This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8249004.cr1.patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/a214b284..4e207e13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=04-05 Stats: 83 lines in 5 files changed: 65 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Thu Oct 14 16:09:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 14 Oct 2021 16:09:48 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: <3KBt9DzHDS01TwRXRZ9Q7IkjejnSsNhpohI-_4CPzY8=.af77a82c-3a15-40bf-abdf-79cdf823602c@github.com> On Sun, 4 Jul 2021 23:39:00 GMT, David Holmes wrote: >> A fix to reduce ThreadsListHandle overhead in relation to handshakes and >> we add sanity checks for ThreadsListHandles higher in the call stack. >> >> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. > > Hi Dan, > > I just updated the bug report. This really isn't addressing the reasons the RFE was filed. > > David @dholmes-ora, @coleenp and @sspitsyn - I've finished reworking the patch and I'm finally happy with how it works. This version has passed Mach5 Tier[1-7] and has mostly finished Mach5 Tier8 (it's in the 24-hour test phase)... ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From cjplummer at openjdk.java.net Thu Oct 14 18:36:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 14 Oct 2021 18:36:52 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: On Thu, 14 Oct 2021 07:44:36 GMT, Richard Reingruber wrote: >> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` is done waiting on it until after `trackAppResume()` is done, and since `trackAppResume()` needs to grab the handlerLock, and you need to grab the handerLock before the threadLock, you need to jump through some lock grabbing/release hoops. However, you are in fact releasing the threadLock for a short time in `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the resumee to potential suspending after the wait has completed and before `trackAppResume()` has been called? > >> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` is done waiting on it until after `trackAppResume()` is done, and since `trackAppResume()` needs to grab the handlerLock, and you need to grab the handerLock before the threadLock, you need to jump through some lock grabbing/release hoops. > > That's correct. > >> However, you are in fact releasing the threadLock for a short time in `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the resumee to potential suspending after the wait has completed and before `trackAppResume()` has been called? > > That's correct too. I wouldn't see an issue with it though. I think this is even a preexisting condition. The current thread can lose the race grabbing threadLock after it was notified to the debugger trying to suspend again (if there wasn't the deadlock of course) and consequently suspendCount can (again) be greater than 0 right after the wait. In that case we simply retry. Ok. So you just need to reacquire the threadLock before the `findThread()` call and before exiting the while loop, and hold it until after the `trackAppResume()` call. I guess it ok then. But this exiting of the handlerLock here and in `blockOnDebuggerSuspend()` is always going to arouse suspicion for anyone that reads the code. The first question will be if the lock does not need to be held here, why grab it in the first place? We know the answer is this lock ordering issue that turns up when `trackAppResume()` is later called, but this will be far from obvious to the reader. It might be possible to make this a bit clearer with some code restructuring, like maybe combining `blockOnDebuggerSuspend()` and `trackAppResume()` into one function (I'm not sure that this will actually help, but maybe something to consider), but at the very least we need some comments calling out why handlerLock is held in the first place and why it is ok to release it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From coleenp at openjdk.java.net Thu Oct 14 22:06:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:49 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 18:03:25 GMT, Markus Gr?nlund wrote: >> 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 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 > > Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > 73: > 74: JfrSymbolTable::JfrSymbolTable() : > 75: _symbol_table(new SymbolTable(this)), I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > 66: template class, typename, size_t> > 67: friend class HashTableHost; > 68: typedef HashTableHost SymbolTable; Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 10:54:18 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/services/finalizerService.cpp line 44: >> >>> 42: _ik(ik), >>> 43: _objects_on_heap(0), >>> 44: _total_finalizers_run(0) {} >> >> Is this hashtable for every InstanceKlass that defines a finalizer? How many are there generally? Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code? > > This hashtable holds a FinalizerEntry for every InstanceKlass that provides a non-empty finalizer method and have allocated at least one object. How many there are in general depends on the application. A ResourceHashtable does not have the concurrency property required, as lookups and inserts will happen as part of object allocation. ok. >> src/hotspot/share/services/finalizerService.cpp line 331: >> >>> 329: } >>> 330: Thread* const thread = Thread::current(); >>> 331: // We use current size >> >> Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup. >> You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive() > > "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." > Thank you, that is true. The only concurrent work required will be to grow the table. > > "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" > > A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? Ok, I see - grow the table. I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Thu Oct 14 22:06:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 14 Oct 2021 22:06:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore wrote: >> "Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup." >> Thank you, that is true. The only concurrent work required will be to grow the table. >> >> "You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()" >> >> A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world? > > Ok, I see - grow the table. > > I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Oct 14 22:31:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:31:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:02:43 GMT, Coleen Phillimore wrote: >> Ok, I see - grow the table. >> >> I'm not sure if you need to ask ik->is_loader_alive() or not, but I think you do. The InstanceKlass is removed from your table during class unloading but before that during concurrent class unloading, the class might not be alive while you look at it and concurrent class unloading hasn't gotten around to removing it yet. Since you save classes regardless of CLD, you have to check if it's alive. See classLoaderDataGraph.cpp ClassLoaderDataGraphIterator for example. The CLDG_lock only keeps the graph from not getting modified, but the classes in it might be dead. > > That said, I don't see where you return an InstanceKlass in the table, which would need this check. Not in class_unloading_do because this follows the _unloading list. So there is already support for concurrent class unloading today in JFR, and the protocol is built around the CLDG_lock. If JFR holds it, concurrent class unloading cannot run. If GC holds it, JFR cannot inspect classes. That's why the table inspection is guarded via the CLDG_lock, for mutual exclusion to avoid this problem. I.e. if concurrent class unloading is in progress, JFR will not inspect the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Thu Oct 14 22:39:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Oct 2021 22:39:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:46:36 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: > >> 66: template class, typename, size_t> >> 67: friend class HashTableHost; >> 68: typedef HashTableHost SymbolTable; > > Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? Maybe :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From duke at openjdk.java.net Thu Oct 14 23:16:54 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Oct 2021 23:16:54 GMT Subject: Integrated: 8275240: Change nested classes in jdk.attach to static nested classes In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 07:20:14 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which in many cases can be avoided. > Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880) This pull request has now been integrated. Changeset: 21df412b Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/21df412bd9a02f0c3f351467951415141d920e03 Stats: 7 lines in 4 files changed: 0 ins; 2 del; 5 mod 8275240: Change nested classes in jdk.attach to static nested classes Reviewed-by: cjplummer, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5904 From ddong at openjdk.java.net Fri Oct 15 01:58:50 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Oct 2021 01:58:50 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong wrote: > I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. > > At present, I have implemented a preliminary version. > > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. > > - Executable interface > Java diagnostic commands need to implement this interface, the interface only contains a simple method: > > /** > * @param output the output when this executable is running > */ > void execute(PrintWriter output); > > > - Add two annotations (@Command and @Parameter) to describe the command meta info > > - Use Factory API to register command, the following forms are supported > > @Command(name = "My.Echo", description = "Echo description") > class Echo implements Executable { > > @Parameter(name = "text", ordinal=0, isMandatory = true) > String text; > > @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") > int repeat; > > @Override > public void execute(PrintWriter out) { > for (int i = 0 ; i < repeat; i++) { > out.println(text); > } > } > } > > Factory.register(Echo.class); > > > > Factory.register("My.Date", output -> { > output.println(new Date()); > }); > > > - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. > > At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). > > In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. > > Any input is appreciated. > > Thanks, > Denghui Hi Thomas, > Hi, > > Interesting proposal. I have some questions. > > * Will hanging java user code block the attach listener thread? If yes, how would you solve that? In my current implementation, I use a simple timeout mechanism to solve this problem. Create a Thread to run the command, and use `java.util.concurrent.Future#get(long, java.util.concurrent.TimeUnit)` to get the result. For more details please refer to Executor.java. > * Will this require changes to the jcmd client, or will this work with any jcmd client, up- and downward the JDK versions? (the nice thing about jcmd is that all the logic resides at the hotspot and I can use any client to talk to any hotspot) > At present, I only extend the DCMD framework and do not modify the code of jcmd. So it works with any jcmd client and jmx client, up and downward JDK versions I think. > Cheers, Thomas > > P.S. I think it may be worthwhile to discuss this on the serviceability-dev mailing list first. Denghui Hi Erik, > To understand what is needed (namespacing, error handling, safety, lifecycle etc.) and if this is actually useful for Java, I think you need to write 2-3 commands for a few popular frameworks, for example Spring. > > If we can't come up with 5-10 commands where this functionality would solve real problems users face, it's unlikely somebody will use it. It will just be a maintenance burden in the JDK. Once an API is added, it's hard to remove. > > The scope of this seem to be JEP level. > > (JFR is not a valid use case, since we don't want to add a dependency on annotation classes in the jdk.jcmd module). Thanks for the comments. I will investigate whether there is a scenario to apply this extension in the current mainstream framework. Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From stuefe at openjdk.java.net Fri Oct 15 04:40:54 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Oct 2021 04:40:54 GMT Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: <_qBZAy0fH7_KuzDya-SIGqXBVrxqroj3Y7TXXxWjb3U=.32f16390-028c-4a1e-8f0d-226e3146fc40@github.com> On Fri, 15 Oct 2021 01:54:16 GMT, Denghui Dong wrote: > Hi Thomas, > > > Hi, > > Interesting proposal. I have some questions. > > > > * Will hanging java user code block the attach listener thread? If yes, how would you solve that? > > In my current implementation, I use a simple timeout mechanism to solve this problem. > > Create a Thread to run the command, and use `java.util.concurrent.Future#get(long, java.util.concurrent.TimeUnit)` to get the result. > > For more details please refer to Executor.java. > > > * Will this require changes to the jcmd client, or will this work with any jcmd client, up- and downward the JDK versions? (the nice thing about jcmd is that all the logic resides at the hotspot and I can use any client to talk to any hotspot) > > At present, I only extend the DCMD framework and do not modify the code of jcmd. So it works with any jcmd client and jmx client, up and downward JDK versions I think. > > > Cheers, Thomas > > P.S. I think it may be worthwhile to discuss this on the serviceability-dev mailing list first. > > Denghui Hi Denghui, thanks for your answers. I'm ambivalent here. I worry about the growing complexity of jcmd, and about unforeseen consequences if we open this door. OTOH I can see this as a useful feature. I'll wait for a consensus. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From duke at openjdk.java.net Fri Oct 15 06:50:06 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Oct 2021 06:50:06 GMT Subject: RFR: 8275322: Change nested classes in java.management to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which can be avoided. ------------- Commit messages: - [PATCH] Change nested classes in java.management to static nested classes Changes: https://git.openjdk.java.net/jdk/pull/5962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275322 Stats: 6 lines in 3 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5962/head:pull/5962 PR: https://git.openjdk.java.net/jdk/pull/5962 From alanb at openjdk.java.net Fri Oct 15 06:54:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Oct 2021 06:54:51 GMT Subject: RFR: 8275322: Change nested classes in java.management to static nested classes In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5962 From dholmes at openjdk.java.net Fri Oct 15 06:56:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 15 Oct 2021 06:56:48 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> On Thu, 14 Oct 2021 16:03:28 GMT, Daniel D. Daugherty wrote: >> A fix to reduce ThreadsListHandle overhead in relation to handshakes and >> we add sanity checks for ThreadsListHandles higher in the call stack. >> >> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8249004.cr1.patch Hi Dan, This looks promising but I'm unclear on some of the details. I can't quite work out the criteria for deciding when to pass the TLH through to Handshake::execute. If it is passed through then the target is checked for being alive ie covered by the TLH. But if the TLH is null then it is assumed that the target is protected elsewhere up the stack and also assumed to be alive. I'm not sure why the two must go together. For example given this code: ThreadsListHandle tlh(current_thread); JavaThread *java_thread; err = JvmtiExport::cv_external_thread_to_JavaThread(tlh.list(), *thread_list, &java_thread, NULL); GetSingleStackTraceClosure op(this, current_thread, *thread_list, max_frame_count); Handshake::execute(&op, &tlh, java_thread); what difference does it make if instead the last line is just: ` Handshake::execute(&op, java_thread);` ? How do I know which form should be used? Thanks, David src/hotspot/share/prims/jvmtiEventController.cpp line 623: > 621: // If we have a JvmtiThreadState, then we've reached the point where > 622: // threads can exist so create a ThreadsListHandle to protect them. > 623: ThreadsListHandle tlh; Good catch on the missing TLH for this code. src/hotspot/share/prims/jvmtiEventController.cpp line 624: > 622: // threads can exist so create a ThreadsListHandle to protect them. > 623: ThreadsListHandle tlh; > 624: for (; state != NULL; state = state->next()) { s/NULL/nullptr/ src/hotspot/share/runtime/handshake.cpp line 361: > 359: } else { > 360: if (tlh_p == nullptr) { > 361: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(target), This should be an assert once this has had some bake time. src/hotspot/share/runtime/thread.cpp line 1771: > 1769: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(this), > 1770: "missing ThreadsListHandle in calling context."); > 1771: if (is_exiting()) { This seems an unrelated change in behaviour ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From rrich at openjdk.java.net Fri Oct 15 09:17:15 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 15 Oct 2021 09:17:15 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v6] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Better comments on lock usage. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/806bceb8..20f1f31b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=04-05 Stats: 26 lines in 1 file changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Fri Oct 15 09:19:48 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 15 Oct 2021 09:19:48 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> Message-ID: <8vKhDapcqqXXhwOM0JAO3o35SPZC7Y_hyrR3yzCyClc=.d211e952-95e0-445b-b936-8df9d8ef874f@github.com> On Thu, 14 Oct 2021 18:33:51 GMT, Chris Plummer wrote: >>> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()` is done waiting on it until after `trackAppResume()` is done, and since `trackAppResume()` needs to grab the handlerLock, and you need to grab the handerLock before the threadLock, you need to jump through some lock grabbing/release hoops. >> >> That's correct. >> >>> However, you are in fact releasing the threadLock for a short time in `blockOnDebuggerSuspend()` after the wait completes. Doesn't this expose the resumee to potential suspending after the wait has completed and before `trackAppResume()` has been called? >> >> That's correct too. I wouldn't see an issue with it though. I think this is even a preexisting condition. The current thread can lose the race grabbing threadLock after it was notified to the debugger trying to suspend again (if there wasn't the deadlock of course) and consequently suspendCount can (again) be greater than 0 right after the wait. In that case we simply retry. > > Ok. So you just need to reacquire the threadLock before the `findThread()` call and before exiting the while loop, and hold it until after the `trackAppResume()` call. I guess it ok then. But this exiting of the handlerLock here and in `blockOnDebuggerSuspend()` is always going to arouse suspicion for anyone that reads the code. The first question will be if the lock does not need to be held here, why grab it in the first place? We know the answer is this lock ordering issue that turns up when `trackAppResume()` is later called, but this will be far from obvious to the reader. It might be possible to make this a bit clearer with some code restructuring, like maybe combining `blockOnDebuggerSuspend()` and `trackAppResume()` into one function (I'm not sure that this will actually help, but maybe something to consider), but at the very least we need some comments calling out why handlerLock is held in the first place and why it is ok to release it. I've added the comments. Maybe I should really combine `blockOnDebuggerSuspend()` and `trackAppResume()` into one function... ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From mgronlun at openjdk.java.net Fri Oct 15 09:27:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:27:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - renames - spelling ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/96a9d6bf..9b418149 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=15-16 Stats: 80 lines in 6 files changed: 0 ins; 0 del; 80 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 From mgronlun at openjdk.java.net Fri Oct 15 09:30:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:43:27 GMT, Coleen Phillimore wrote: >> Markus Gr?nlund has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/share/jfr/support/jfrSymbolTable.cpp line 75: > >> 73: >> 74: JfrSymbolTable::JfrSymbolTable() : >> 75: _symbol_table(new SymbolTable(this)), > > I'm confused about which symbol table this is. Is this the same SymbolTable as classfile/symbolTable.cpp? that instance is assumed to be a singleton. Is this a different SymbolTable and can it have a different name (thought it was JfrSymbolTable). Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Fri Oct 15 09:30:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 15 Oct 2021 09:30:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v16] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:36:30 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68: >> >>> 66: template class, typename, size_t> >>> 67: friend class HashTableHost; >>> 68: typedef HashTableHost SymbolTable; >> >> Oh here it is. Since it's an enclosed type, can you rename it something simpler like Symbols and the other Strings? > > Maybe :) Renamed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From ddong at openjdk.java.net Fri Oct 15 10:58:29 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 15 Oct 2021 10:58:29 GMT Subject: RFR: 8275259: Add support for Java level DCmd [v2] In-Reply-To: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: > I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. > > At present, I have implemented a preliminary version. > > In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. > > - Executable interface > Java diagnostic commands need to implement this interface, the interface only contains a simple method: > > /** > * @param output the output when this executable is running > */ > void execute(PrintWriter output); > > > - Add two annotations (@Command and @Parameter) to describe the command meta info > > - Use Factory API to register command, the following forms are supported > > @Command(name = "My.Echo", description = "Echo description") > class Echo implements Executable { > > @Parameter(name = "text", ordinal=0, isMandatory = true) > String text; > > @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") > int repeat; > > @Override > public void execute(PrintWriter out) { > for (int i = 0 ; i < repeat; i++) { > out.println(text); > } > } > } > > Factory.register(Echo.class); > > > > Factory.register("My.Date", output -> { > output.println(new Date()); > }); > > > - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. > > At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). > > In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. > > Any input is appreciated. > > Thanks, > Denghui Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: print argument key if not found ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5938/files - new: https://git.openjdk.java.net/jdk/pull/5938/files/770b6aef..1f085c26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5938&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5938&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5938/head:pull/5938 PR: https://git.openjdk.java.net/jdk/pull/5938 From dfuchs at openjdk.java.net Fri Oct 15 11:44:48 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 15 Oct 2021 11:44:48 GMT Subject: RFR: 8275322: Change nested classes in java.management to static nested classes In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5962 From rrich at openjdk.java.net Fri Oct 15 11:54:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 15 Oct 2021 11:54:49 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: <8vKhDapcqqXXhwOM0JAO3o35SPZC7Y_hyrR3yzCyClc=.d211e952-95e0-445b-b936-8df9d8ef874f@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> <8vKhDapcqqXXhwOM0JAO3o35SPZC7Y_hyrR3yzCyClc=.d211e952-95e0-445b-b936-8df9d8ef874f@github.com> Message-ID: On Fri, 15 Oct 2021 09:17:12 GMT, Richard Reingruber wrote: >> Ok. So you just need to reacquire the threadLock before the `findThread()` call and before exiting the while loop, and hold it until after the `trackAppResume()` call. I guess it ok then. But this exiting of the handlerLock here and in `blockOnDebuggerSuspend()` is always going to arouse suspicion for anyone that reads the code. The first question will be if the lock does not need to be held here, why grab it in the first place? We know the answer is this lock ordering issue that turns up when `trackAppResume()` is later called, but this will be far from obvious to the reader. It might be possible to make this a bit clearer with some code restructuring, like maybe combining `blockOnDebuggerSuspend()` and `trackAppResume()` into one function (I'm not sure that this will actually help, but maybe something to consider), but at the very least we need some comments calling out why handlerLock is held in the first place and why it is ok to release it. > > I've added the comments. Maybe I should really combine `blockOnDebuggerSuspend()` and `trackAppResume()` into one function... Hm, I think this can be simplified by swaping blockOnDebuggerSuspend() and trackAppResume(). Can't try it today but will on Monday. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From mchung at openjdk.java.net Fri Oct 15 15:51:47 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 15 Oct 2021 15:51:47 GMT Subject: RFR: 8275322: Change nested classes in java.management to static nested classes In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5962 From sspitsyn at openjdk.java.net Fri Oct 15 18:16:53 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 15 Oct 2021 18:16:53 GMT Subject: RFR: 8275322: Change nested classes in java.management to static nested classes In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5962 From coleenp at openjdk.java.net Fri Oct 15 18:16:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 18:16:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v17] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 09:27:54 GMT, Markus Gr?nlund wrote: >> 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 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 > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - renames > - spelling Thanks for doing the renames. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4731 From coleenp at openjdk.java.net Fri Oct 15 18:34:48 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 18:34:48 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: On Thu, 14 Oct 2021 16:03:28 GMT, Daniel D. Daugherty wrote: >> A fix to reduce ThreadsListHandle overhead in relation to handshakes and >> we add sanity checks for ThreadsListHandles higher in the call stack. >> >> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8249004.cr1.patch This has more moving pieces than the last version. I'm a bit uneasy about passing NULL as a thread to Handshake::execute(). This shouldn't be something that should happen. src/hotspot/share/runtime/handshake.cpp line 358: > 356: bool target_is_dead = false; > 357: if (target == nullptr) { > 358: target_is_dead = true; Why would you pass a NULL target thread to Handshake::execute? Why would the caller not check if the target is dead? src/hotspot/share/runtime/thread.cpp line 497: > 495: // placement somewhere in the calling context. > 496: bool Thread::is_JavaThread_protected_by_my_ThreadsList(const JavaThread* p) { > 497: Thread* current_thread = Thread::current(); Shouldn't you call this on the current thread as "this" argument? ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Fri Oct 15 18:34:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 18:34:49 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> Message-ID: On Fri, 15 Oct 2021 06:45:02 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr1.patch > > src/hotspot/share/runtime/thread.cpp line 1771: > >> 1769: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(this), >> 1770: "missing ThreadsListHandle in calling context."); >> 1771: if (is_exiting()) { > > This seems an unrelated change in behaviour ?? So suspend_thread and resume thread's caller already takes a ThreadsListHandle so this is unnecessary and never happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Oct 15 22:26:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Oct 2021 22:26:53 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> Message-ID: On Fri, 15 Oct 2021 06:34:42 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr1.patch > > src/hotspot/share/prims/jvmtiEventController.cpp line 623: > >> 621: // If we have a JvmtiThreadState, then we've reached the point where >> 622: // threads can exist so create a ThreadsListHandle to protect them. >> 623: ThreadsListHandle tlh; > > Good catch on the missing TLH for this code. It wasn't quite missing from the baseline code. This version of execute(): `Handshake::execute(HandshakeClosure* hs_cl, JavaThread* target)` used to always create a ThreadsListHandle. I added a `ThreadsListHandle*` parameter to that version and created a wrapper with the existing signature to pass `nullptr` to the execute() version with the `ThreadsListHandle*` parameter. What that means is that all existing callers of: `Handshake::execute(HandshakeClosure* hs_cl, JavaThread* target)` no longer had a ThreadsListHandle created for them. With the new sanity check in place, I shook the trees to make sure that we had explicit ThreadsListHandles in place for the locations that needed them. `JvmtiEventControllerPrivate::recompute_enabled()` happened to be one of the places where the ThreadsListHandle created by execute() was hiding the fact that `recompute_enabled()` needed one. > src/hotspot/share/prims/jvmtiEventController.cpp line 624: > >> 622: // threads can exist so create a ThreadsListHandle to protect them. >> 623: ThreadsListHandle tlh; >> 624: for (; state != NULL; state = state->next()) { > > s/NULL/nullptr/ Missed that one. Fixed. > src/hotspot/share/runtime/handshake.cpp line 361: > >> 359: } else { >> 360: if (tlh_p == nullptr) { >> 361: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(target), > > This should be an assert once this has had some bake time. Agreed. All of the `guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(),...` calls should be changed to asserts down the road. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Oct 15 22:26:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Oct 2021 22:26:55 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: On Fri, 15 Oct 2021 18:20:12 GMT, Coleen Phillimore wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr1.patch > > src/hotspot/share/runtime/handshake.cpp line 358: > >> 356: bool target_is_dead = false; >> 357: if (target == nullptr) { >> 358: target_is_dead = true; > > Why would you pass a NULL target thread to Handshake::execute? Why would the caller not check if the target is dead? The `NULL` target thread being passed in is actually handled by the baseline code: ThreadsListHandle tlh; if (tlh.includes(target)) { `tlh.includes(target)` returns `false` when `target` is `NULL/nullptr`. I just made the already handled situation more explicit. > Why would the caller not check if the target is dead? Hmmm... It's hard for me to answer that question since I didn't write the original code. The test code that calls `WB_HandshakeWalkStack()` or `WB_AsyncHandshakeWalkStack()` can call those functions with a `thread_handle` that translates into a `thread_oop` that returns a `NULL` `JavaThread*`. See the comment that I added to `WB_AsyncHandshakeWalkStack()` above. > src/hotspot/share/runtime/thread.cpp line 497: > >> 495: // placement somewhere in the calling context. >> 496: bool Thread::is_JavaThread_protected_by_my_ThreadsList(const JavaThread* p) { >> 497: Thread* current_thread = Thread::current(); > > Shouldn't you call this on the current thread as "this" argument? I modeled the new check after the existing: bool Thread::is_JavaThread_protected(const JavaThread* p) { which is also a static function. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Oct 15 22:26:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Oct 2021 22:26:55 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> Message-ID: <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> On Fri, 15 Oct 2021 18:27:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/thread.cpp line 1771: >> >>> 1769: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(this), >>> 1770: "missing ThreadsListHandle in calling context."); >>> 1771: if (is_exiting()) { >> >> This seems an unrelated change in behaviour ?? > > So suspend_thread and resume thread's caller already takes a ThreadsListHandle so this is unnecessary and never happens. > This seems an unrelated change in behaviour ?? Actually this is equivalent code. The baseline code does this: ThreadsListHandle tlh; if (!tlh.includes(this)) { log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); return false; } What that code means is: if `this` thread does not appear in the newly created ThreadsListHandle's list, then `this` thread has called `java_suspend()` after `this` thread has exited. That's the only way that `this` thread could be missing from a newly created ThreadsListHandle's list. All I've done here is get rid of the ThreadsListHandle, verify that the calling context is protecting `this` and switch to an `is_exiting()` call. > So suspend_thread and resume thread's caller already takes a ThreadsListHandle > so this is unnecessary and never happens. I presume @coleenp is saying that the `is_exiting()` check is not necessary. That might be true, it might not be true. I was trying to create equivalent code without creating a nested ThreadsListHandle here and I think I've done that. I actually think it might be possible for a JVM/TI event handler to fire after the thread has set is_exiting() and for that event handler to call SuspendThread() which could get us to this point. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Oct 15 22:31:16 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 15 Oct 2021 22:31:16 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v7] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: > A fix to reduce ThreadsListHandle overhead in relation to handshakes and > we add sanity checks for ThreadsListHandles higher in the call stack. > > This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR - change NULL to nullptr. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/4e207e13..48416864 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From mgronlun at openjdk.java.net Sat Oct 16 15:24:52 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 16 Oct 2021 15:24:52 GMT Subject: RFR: 8266936: Add a finalization JFR event [v18] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: ThreadBlockInVM instead of ThreadToNativeFromVM for sampling exclusion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/9b418149..d10eb309 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From dcubed at openjdk.java.net Sat Oct 16 15:51:50 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 16 Oct 2021 15:51:50 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> Message-ID: On Fri, 15 Oct 2021 06:54:10 GMT, David Holmes wrote: > This looks promising but I'm unclear on some of the details. I can't quite work out > the criteria for deciding when to pass the TLH through to Handshake::execute. If > it is passed through then the target is checked for being alive ie covered by the > TLH. But if the TLH is null then it is assumed that the target is protected elsewhere > up the stack and also assumed to be alive. I'm not sure why the two must go > together. For example given this code: > > ``` > ThreadsListHandle tlh(current_thread); > JavaThread *java_thread; > err = JvmtiExport::cv_external_thread_to_JavaThread(tlh.list(), *thread_list, &java_thread, NULL); > GetSingleStackTraceClosure op(this, current_thread, *thread_list, max_frame_count); > Handshake::execute(&op, &tlh, java_thread); > ``` > > what difference does it make if instead the last line is just: > > ` Handshake::execute(&op, java_thread);` > > ? How do I know which form should be used? Hmmm... This is a really good observation. When I was putting together this patch (the second time), my criteria was fairly simple: if we were calling `Handshake::execute()` and we happened to have a `ThreadsListHandle` in hand, then I switched to the new version of `Handshake::execute()` that takes a `ThreadsListHandle*`. As for what difference does it make, when we pass in a `ThreadsListHandle`, then we're saying "This is the `ThreadsListHandle` that protects the target JavaThread." and that's the _only_ `ThreadsListHandle` that we search. If we call the `Handshake::execute()` form that does not take a `ThreadsListHandle`, then we might end up searching all of the `ThreadsListHandles` that are associated with the calling thread. Since we stop on first match, we might only search the first one, but if the target JavaThread isn't in the first one, then we'll continue to search the next one and so on. Of course, down the road, if we end up changing code like this: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(target), "missing ThreadsListHandle in calling context."); into an assert(), then we won't be doing any search in 'release' bits and then the `Handshake::execute()` that takes a `ThreadsListHandle*` will be more expensive in release bits. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Sat Oct 16 16:02:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 16 Oct 2021 16:02:08 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v8] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: > A fix to reduce ThreadsListHandle overhead in relation to handshakes and > we add sanity checks for ThreadsListHandles higher in the call stack. > > This fix was tested with Mach5 Tier[1-8]; Tier8 is still running. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: coleenp CR - add comments to clarify what WB_HandshakeReadMonitors() and WB_HandshakeWalkStack() expect. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/48416864..9518a9a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=06-07 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677 PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Sat Oct 16 16:02:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 16 Oct 2021 16:02:09 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: On Fri, 15 Oct 2021 21:58:38 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/handshake.cpp line 358: >> >>> 356: bool target_is_dead = false; >>> 357: if (target == nullptr) { >>> 358: target_is_dead = true; >> >> Why would you pass a NULL target thread to Handshake::execute? Why would the caller not check if the target is dead? > > The `NULL` target thread being passed in is actually handled by the baseline code: > > > ThreadsListHandle tlh; > if (tlh.includes(target)) { > > > `tlh.includes(target)` returns `false` when `target` is `NULL/nullptr`. > I just made the already handled situation more explicit. > >> Why would the caller not check if the target is dead? > > Hmmm... It's hard for me to answer that question since I didn't write > the original code. The test code that calls `WB_HandshakeWalkStack()` > or `WB_AsyncHandshakeWalkStack()` can call those functions with > a `thread_handle` that translates into a `thread_oop` that returns a > `NULL` `JavaThread*`. > > See the comment that I added to `WB_AsyncHandshakeWalkStack()` above. Update: I've added comments to WB_HandshakeReadMonitors() and WB_HandshakeWalkStack() to clarify their expectations. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Sat Oct 16 16:23:54 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 16 Oct 2021 16:23:54 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> Message-ID: On Fri, 15 Oct 2021 22:19:15 GMT, Daniel D. Daugherty wrote: >> So suspend_thread and resume thread's caller already takes a ThreadsListHandle so this is unnecessary and never happens. > >> This seems an unrelated change in behaviour ?? > > Actually this is equivalent code. The baseline code does this: > > ThreadsListHandle tlh; > if (!tlh.includes(this)) { > log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > return false; > } > > > What that code means is: if `this` thread does not appear in the newly created > ThreadsListHandle's list, then `this` thread has called `java_suspend()` after > `this` thread has exited. That's the only way that `this` thread could be missing > from a newly created ThreadsListHandle's list. > > All I've done here is get rid of the ThreadsListHandle, verify that the calling > context is protecting `this` and switch to an `is_exiting()` call. > >> So suspend_thread and resume thread's caller already takes a ThreadsListHandle >> so this is unnecessary and never happens. > > I presume @coleenp is saying that the `is_exiting()` check is not necessary. > > That might be true, it might not be true. I was trying to create equivalent > code without creating a nested ThreadsListHandle here and I think I've > done that. I actually think it might be possible for a JVM/TI event handler > to fire after the thread has set is_exiting() and for that event handler to > call SuspendThread() which could get us to this point. On rereading all of these comments and the current baseline code, I have to clarify one thing: There is a minor change in behavior caused by switching from a `ThreadsListHandle::includes()` check to a `JavaThread::is_exiting()` check. The `JavaThread::is_exiting()` will return true before the target JavaThread is removed from the system's current ThreadsList. So the `JavaThread::is_exiting()` check will return true faster and the `ThreadsListHandle::includes()` check. However, that change in behavior does not result in a change in behavior for a suspend thread request. Here's the relevant code: src/hotspot/share/runtime/thread.cpp: void JavaThread::exit(bool destroy_vm, ExitType exit_type) { // The careful dance between thread suspension and exit is handled here. // Since we are in thread_in_vm state and suspension is done with handshakes, // we can just put in the exiting state and it will be correctly handled. set_terminated(_thread_exiting); // Remove from list of active threads list, and notify VM thread if we are the last non-daemon thread Threads::remove(this, daemon); } When we changed the suspend thread mechanism to use handshakes, we made it so that once the JavaThread called `set_terminated(_thread_exiting)` it no longer had to honor a suspend thread request. Summary: Yes, the `is_exiting()` call will result in detecting the exiting JavaThread sooner than the `ThreadsListHandle::includes()` check. However, it will not result in a change in suspend thread behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From david.holmes at oracle.com Sun Oct 17 12:27:19 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Oct 2021 22:27:19 +1000 Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> Message-ID: <1bd34cd4-52b7-477e-4b59-9e986e3598ea@oracle.com> On 16/10/2021 8:26 am, Daniel D.Daugherty wrote: > On Fri, 15 Oct 2021 06:34:42 GMT, David Holmes wrote: > >>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >>> >>> 8249004.cr1.patch >> >> src/hotspot/share/prims/jvmtiEventController.cpp line 623: >> >>> 621: // If we have a JvmtiThreadState, then we've reached the point where >>> 622: // threads can exist so create a ThreadsListHandle to protect them. >>> 623: ThreadsListHandle tlh; >> >> Good catch on the missing TLH for this code. > > It wasn't quite missing from the baseline code. This version of execute(): > > `Handshake::execute(HandshakeClosure* hs_cl, JavaThread* target)` > > used to always create a ThreadsListHandle. I added a `ThreadsListHandle*` > parameter to that version and created a wrapper with the existing signature > to pass `nullptr` to the execute() version with the `ThreadsListHandle*` > parameter. What that means is that all existing callers of: > > `Handshake::execute(HandshakeClosure* hs_cl, JavaThread* target)` > > no longer had a ThreadsListHandle created for them. With the new sanity > check in place, I shook the trees to make sure that we had explicit > ThreadsListHandles in place for the locations that needed them. > > `JvmtiEventControllerPrivate::recompute_enabled()` happened to be > one of the places where the ThreadsListHandle created by execute() > was hiding the fact that `recompute_enabled()` needed one. Yup and that is exactly why I said good catch on finding the missing TLH. Cheers, David >> src/hotspot/share/prims/jvmtiEventController.cpp line 624: >> >>> 622: // threads can exist so create a ThreadsListHandle to protect them. >>> 623: ThreadsListHandle tlh; >>> 624: for (; state != NULL; state = state->next()) { >> >> s/NULL/nullptr/ > > Missed that one. Fixed. > >> src/hotspot/share/runtime/handshake.cpp line 361: >> >>> 359: } else { >>> 360: if (tlh_p == nullptr) { >>> 361: guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(target), >> >> This should be an assert once this has had some bake time. > > Agreed. All of the `guarantee(Thread::is_JavaThread_protected_by_my_ThreadsList(),...` > calls should be changed to asserts down the road. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4677 > From dholmes at openjdk.java.net Sun Oct 17 12:48:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 17 Oct 2021 12:48:55 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: On Fri, 15 Oct 2021 22:04:16 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 497: >> >>> 495: // placement somewhere in the calling context. >>> 496: bool Thread::is_JavaThread_protected_by_my_ThreadsList(const JavaThread* p) { >>> 497: Thread* current_thread = Thread::current(); >> >> Shouldn't you call this on the current thread as "this" argument? > > I modeled the new check after the existing: > > > bool Thread::is_JavaThread_protected(const JavaThread* p) { > > > which is also a static function. While the name is somewhat ungainly - and unnecessarily detailed given `is_JavaThread_protected` has a similar constraint - it should be a static function as given because it must only be called on the current thread, and an instance method would give the false impression that it could be called on any thread. That said it should be possible to write that code block only once and reuse it. And the name as I said is somewhat ungainly. You could even have: static bool is_JavaThread_protected(const JavaThread* p, bool checkTLHOnly = false) { ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dholmes at openjdk.java.net Sun Oct 17 12:54:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 17 Oct 2021 12:54:53 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> Message-ID: On Sat, 16 Oct 2021 16:21:08 GMT, Daniel D. Daugherty wrote: >>> This seems an unrelated change in behaviour ?? >> >> Actually this is equivalent code. The baseline code does this: >> >> ThreadsListHandle tlh; >> if (!tlh.includes(this)) { >> log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); >> return false; >> } >> >> >> What that code means is: if `this` thread does not appear in the newly created >> ThreadsListHandle's list, then `this` thread has called `java_suspend()` after >> `this` thread has exited. That's the only way that `this` thread could be missing >> from a newly created ThreadsListHandle's list. >> >> All I've done here is get rid of the ThreadsListHandle, verify that the calling >> context is protecting `this` and switch to an `is_exiting()` call. >> >>> So suspend_thread and resume thread's caller already takes a ThreadsListHandle >>> so this is unnecessary and never happens. >> >> I presume @coleenp is saying that the `is_exiting()` check is not necessary. >> >> That might be true, it might not be true. I was trying to create equivalent >> code without creating a nested ThreadsListHandle here and I think I've >> done that. I actually think it might be possible for a JVM/TI event handler >> to fire after the thread has set is_exiting() and for that event handler to >> call SuspendThread() which could get us to this point. > > On rereading all of these comments and the current baseline code, I have > to clarify one thing: > > There is a minor change in behavior caused by switching from a > `ThreadsListHandle::includes()` check to a `JavaThread::is_exiting()` > check. The `JavaThread::is_exiting()` will return true before the target > JavaThread is removed from the system's current ThreadsList. So the > `JavaThread::is_exiting()` check will return true faster and the > `ThreadsListHandle::includes()` check. > > However, that change in behavior does not result in a change in > behavior for a suspend thread request. Here's the relevant code: > > > src/hotspot/share/runtime/thread.cpp: > void JavaThread::exit(bool destroy_vm, ExitType exit_type) { > > > // The careful dance between thread suspension and exit is handled here. > // Since we are in thread_in_vm state and suspension is done with handshakes, > // we can just put in the exiting state and it will be correctly handled. > set_terminated(_thread_exiting); > > > > // Remove from list of active threads list, and notify VM thread if we are the last non-daemon thread > Threads::remove(this, daemon); > > > } > > > When we changed the suspend thread mechanism to use handshakes, we > made it so that once the JavaThread called `set_terminated(_thread_exiting)` > it no longer had to honor a suspend thread request. > > Summary: Yes, the `is_exiting()` call will result in detecting the exiting > JavaThread sooner than the `ThreadsListHandle::includes()` check. > However, it will not result in a change in suspend thread behavior. The `is_exiting` check seems unnecessary as the handshake code will not handshake with an exiting thread. The nested TLH was unnecessary too AFAICS. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Mon Oct 18 07:37:15 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 07:37:15 GMT Subject: RFR: 8275384: Change nested classes in jdk.jconsole to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which can be avoided. ------------- Commit messages: - [PATCH] Change nested classes in jdk.jconsole to static nested classes Changes: https://git.openjdk.java.net/jdk/pull/5974/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5974&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275384 Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/5974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5974/head:pull/5974 PR: https://git.openjdk.java.net/jdk/pull/5974 From duke at openjdk.java.net Mon Oct 18 07:39:04 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 07:39:04 GMT Subject: RFR: 8275385: Change nested classes in jdk.jdi to static nested classes Message-ID: Non-static classes hold a link to their parent classes, which can be avoided. ------------- Commit messages: - [PATCH] Change nested classes in jdk.jdi to static nested classes Changes: https://git.openjdk.java.net/jdk/pull/5978/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5978&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275385 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5978.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5978/head:pull/5978 PR: https://git.openjdk.java.net/jdk/pull/5978 From alanb at openjdk.java.net Mon Oct 18 07:43:51 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 18 Oct 2021 07:43:51 GMT Subject: RFR: 8275384: Change nested classes in jdk.jconsole to static nested classes In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 20:32:43 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5974 From mgronlun at openjdk.java.net Mon Oct 18 08:29:46 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 08:29:46 GMT Subject: RFR: 8266936: Add a finalization JFR event [v19] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: relax memory ordering constraint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/d10eb309..85a46263 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=17-18 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 From sspitsyn at openjdk.java.net Mon Oct 18 10:01:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 18 Oct 2021 10:01:54 GMT Subject: RFR: 8275384: Change nested classes in jdk.jconsole to static nested classes In-Reply-To: References: Message-ID: On Sat, 16 Oct 2021 20:32:43 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5974 From sspitsyn at openjdk.java.net Mon Oct 18 10:04:01 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 18 Oct 2021 10:04:01 GMT Subject: RFR: 8275385: Change nested classes in jdk.jdi to static nested classes In-Reply-To: References: Message-ID: <6sBv1eFFe8cmENUO0Q3S0EQEyxOKpmsKszzFLekM2SE=.ce6186ec-b334-4085-aef1-b0dfe67f82a5@github.com> On Sun, 17 Oct 2021 17:28:37 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5978 From duke at openjdk.java.net Mon Oct 18 12:04:54 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 18 Oct 2021 12:04:54 GMT Subject: Integrated: 8275322: Change nested classes in java.management to static nested classes In-Reply-To: References: Message-ID: <-XMj5W9GO6YNKpM26R700A8cqh5hK8QfXtyiCqYMUT0=.2b0f597e-aa6d-4807-98d1-10e4b983a1d0@github.com> On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. This pull request has now been integrated. Changeset: 1afddb25 Author: Andrey Turbanov Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/1afddb2560504c533d30b2f79d735f59f519e7c5 Stats: 6 lines in 3 files changed: 0 ins; 1 del; 5 mod 8275322: Change nested classes in java.management to static nested classes Reviewed-by: alanb, dfuchs, mchung, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5962 From denghui.ddh at alibaba-inc.com Mon Oct 18 14:56:05 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 18 Oct 2021 22:56:05 +0800 Subject: =?UTF-8?B?U29tZSBjYWxsIHNpdGVzIGRvbid0IHBhc3MgJ3NpemUnIHRvIHNoYXJlZFJ1bnRpbWU6OmR0?= =?UTF-8?B?cmFjZV9vYmplY3RfYWxsb2MvZHRyYWNlX29iamVjdF9hbGxvY19iYXNl?= Message-ID: <32b96f30-6427-4b8e-adf4-0d92720aeb99.denghui.ddh@alibaba-inc.com> Hi, A new param named 'size' was added to sharedRuntime::dtrace_object_alloc/dtrace_object_alloc_base in JDK-8039904("dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated"). But in some places where these two functions are called, this new parameter is not passed, such as TemplateTable::_new and PhaseMacroExpand::expand_dtrace_alloc_probe. Was it intentional or should we fix it? Thanks, Denghui -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.java.net Mon Oct 18 16:11:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 18 Oct 2021 16:11:50 GMT Subject: RFR: 8275384: Change nested classes in jdk.jconsole to static nested classes In-Reply-To: References: Message-ID: <57BYXYWF3qjV5nt76jktKd0y43K-KDSkDoeJLdEzMDM=.10774f96-7c83-44d9-9073-7b1d45ab22a2@github.com> On Sat, 16 Oct 2021 20:32:43 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5974 From egahlin at openjdk.java.net Mon Oct 18 16:27:55 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 18 Oct 2021 16:27:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 15:23:35 GMT, Markus Gr?nlund wrote: >> 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 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 > > Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: > > - localize > - cleanup > - FinalizerStatistics Marked as reviewed by egahlin (Reviewer). src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > 69: } > 70: > 71: extraneous whitespace? test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > 96: case TEST_CLASS_NAME: { > 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); > 98: foundTestClassName = true; Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:38:50 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:38:50 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:42:58 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java line 98: > >> 96: case TEST_CLASS_NAME: { >> 97: Asserts.assertTrue(event.getString("codeSource").startsWith("file://")); >> 98: foundTestClassName = true; > > Could we (sanity) check "objects" and "totalFinalzersRun" fields as well? It's risky to do because of the non-deterministic nature of when the Finalizer thread runs (if at all). The best I could think of is to check if either field is 0 or more, but that becomes so weak it's not much of a sanity check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:53 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:53 GMT Subject: RFR: 8266936: Add a finalization JFR event [v20] In-Reply-To: References: Message-ID: > 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 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 Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: no constexpr for constant values ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4731/files - new: https://git.openjdk.java.net/jdk/pull/4731/files/85a46263..b3268c90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=18-19 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 From mgronlun at openjdk.java.net Mon Oct 18 16:51:54 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:54 GMT Subject: RFR: 8266936: Add a finalization JFR event [v12] In-Reply-To: References: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com> Message-ID: <_fUcg-t8JOZ8qDTmngQnSHCnofBQLQIbClMfd0V92i0=.67daf704-61cc-4b14-8a54-dd41da28482c@github.com> On Fri, 24 Sep 2021 22:31:18 GMT, Mandy Chung wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> no precompiled headers and mtServiceability nmt classification > > Hi Markus, > > It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES. Thank you for staying around with this protracted PR. Thanks @mlchung , @coleenp and @egahlin for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:51:55 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:51:55 GMT Subject: RFR: 8266936: Add a finalization JFR event [v10] In-Reply-To: References: Message-ID: On Tue, 31 Aug 2021 08:45:54 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision: >> >> - localize >> - cleanup >> - FinalizerStatistics > > src/java.base/share/classes/java/lang/ref/Finalizer.java line 71: > >> 69: } >> 70: >> 71: > > extraneous whitespace? I think this version is outdated, and the extra whitespace was removed in later versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From mgronlun at openjdk.java.net Mon Oct 18 16:55:56 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 16:55:56 GMT Subject: Integrated: 8266936: Add a finalization JFR event In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 19:47:26 GMT, Markus Gr?nlund wrote: > 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 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 This pull request has now been integrated. Changeset: 72a976ef Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/72a976ef05fc2c62657920a560a0abc60b27c852 Stats: 1917 lines in 36 files changed: 1375 ins; 409 del; 133 mod 8266936: Add a finalization JFR event Reviewed-by: coleenp, mchung, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/4731 From dcubed at openjdk.java.net Mon Oct 18 18:06:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:06:09 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Message-ID: This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. ------------- Commit messages: - JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Changes: https://git.openjdk.java.net/jdk/pull/5994/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5994&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275436 Stats: 170 lines in 10 files changed: 3 ins; 138 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/5994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5994/head:pull/5994 PR: https://git.openjdk.java.net/jdk/pull/5994 From mgronlun at openjdk.java.net Mon Oct 18 18:19:01 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Oct 2021 18:19:01 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:58:25 GMT, Daniel D. Daugherty wrote: > This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. Thanks for creating the backout Dan, looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5994 From dcubed at openjdk.java.net Mon Oct 18 18:19:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:19:02 GMT Subject: RFR: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 18:14:16 GMT, Markus Gr?nlund wrote: >> This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. > > Thanks for creating the backout Dan, looks good. @mgronlun - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/5994 From dcubed at openjdk.java.net Mon Oct 18 18:28:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 18 Oct 2021 18:28:56 GMT Subject: Integrated: JDK-8275436 [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:58:25 GMT, Daniel D. Daugherty wrote: > This reverts commit 31500692d1503cb73249e0425e6930aaaa49258a. This pull request has now been integrated. Changeset: a03119ce Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/a03119ce1a34642565c669bd2471f52eec088b96 Stats: 170 lines in 10 files changed: 3 ins; 138 del; 29 mod 8275436: [BACKOUT] JDK-8271949 dumppath in -XX:FlightRecorderOptions does not affect Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/5994 From rrich at openjdk.java.net Mon Oct 18 20:02:21 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 18 Oct 2021 20:02:21 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Call blockOnDebuggerSuspend() after setup of the resumer tracking. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/20f1f31b..0b0fef0e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=05-06 Stats: 95 lines in 2 files changed: 31 ins; 36 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Mon Oct 18 20:17:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 18 Oct 2021 20:17:49 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v4] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <6rXXWKHYtPW_3Bp3v6ziMmdNd1DpJkq6toRO8gTh2yU=.9d492d50-4096-4550-a842-ec49559cfe3b@github.com> <3t5sZrIhBHECRzlPtuDu5vECPJ63DvvlXj-MZekq1AE=.ce09aebb-d1d8-4899-8448-ca1de6fe40cc@github.com> <8vKhDapcqqXXhwOM0JAO3o35SPZC7Y_hyrR3yzCyClc=.d211e952-95e0-445b-b936-8df9d8ef874f@github.com> Message-ID: <2RvL3drGei6_ROpUkTrU0wFAN3_lyky5b5N65Wqtavo=.c1dc8bb8-177b-4720-840c-51a7436fecc7@github.com> On Fri, 15 Oct 2021 11:52:09 GMT, Richard Reingruber wrote: > > > Hm, I think this can be simplified by swaping blockOnDebuggerSuspend() and trackAppResume(). Can't try it today but will on Monday. I've done that with commit https://github.com/openjdk/jdk/pull/5849/commits/0b0fef0e6670c20a0e1e34323847c5a622878469. The locking is clearer I would say. Since `resumeFrameDepth` is now set before resumee's suspendCount is 0 we must block debugger suspends only if `!handlingAppResume` because then we know resumee's suspendCount actually is 0. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From amenkov at openjdk.java.net Mon Oct 18 22:45:47 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 18 Oct 2021 22:45:47 GMT Subject: RFR: 8275385: Change nested classes in jdk.jdi to static nested classes In-Reply-To: References: Message-ID: On Sun, 17 Oct 2021 17:28:37 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5978 From duke at openjdk.java.net Mon Oct 18 23:45:52 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 18 Oct 2021 23:45:52 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 19:22:40 GMT, Chris Plummer wrote: >> Hey Chris, is there any update on this? I've revised the Problem section so I think we're waiting on the CSR ticket to be updated accordingly and for someone to be assigned for the CSR review. > >> Hey Chris, is there any update on this? I've revised the Problem section so I think we're waiting on the CSR ticket to be updated accordingly and for someone to be assigned for the CSR review. > > Ok. I updated the CSR with your changes. I'll try to find someone to review it. @plummercj Looks like Serguei Spitsyn approved this about a week ago, so I wanted to make sure this is moving along. Is the CSR proposal now approved or is there a need for another reviewer? ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Tue Oct 19 01:02:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 01:02:47 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: Message-ID: <0514Y42P1_Hw77-L6wGCqWjdRYQ8bzsyy3ImTDbiq6M=.a186968f-11cb-44cb-9332-0a27181c8958@github.com> On Thu, 30 Sep 2021 19:22:40 GMT, Chris Plummer wrote: >> Hey Chris, is there any update on this? I've revised the Problem section so I think we're waiting on the CSR ticket to be updated accordingly and for someone to be assigned for the CSR review. > >> Hey Chris, is there any update on this? I've revised the Problem section so I think we're waiting on the CSR ticket to be updated accordingly and for someone to be assigned for the CSR review. > > Ok. I updated the CSR with your changes. I'll try to find someone to review it. > @plummercj Looks like Serguei Spitsyn approved this about a week ago, so I wanted to make sure this is moving along. Is the CSR proposal now approved or is there a need for another reviewer? It looks like it needed for me to click on "finalize" so I've done that. Now it is in the "Finalized" state and is I believe waiting final approval by the CSR committee, which I think will result in closing the CSR as "Approved", and you can then complete the review of the PR and push the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From mgronlun at openjdk.java.net Tue Oct 19 10:05:15 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 10:05:15 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: > Greetings, > > This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. > > Testing: in progress > > Thanks > Markus > > PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6001/files - new: https://git.openjdk.java.net/jdk/pull/6001/files/a5de3988..7b17ff5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6001&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6001&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6001/head:pull/6001 PR: https://git.openjdk.java.net/jdk/pull/6001 From egahlin at openjdk.java.net Tue Oct 19 12:22:56 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 19 Oct 2021 12:22:56 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 10:05:15 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. >> >> Testing: tier1-3, jdk_jfr >> >> Thanks >> Markus >> >> PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > header Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From lkorinth at openjdk.java.net Tue Oct 19 12:23:55 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 12:23:55 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 05:49:24 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/asm/codeBuffer.cpp line 143: > >> 141: NOT_PRODUCT(clear_strings()); >> 142: >> 143: assert(_default_oop_recorder.allocated_on_stack_or_embedded(), "should be embedded object"); > > It might have been better to do this name change separately, to reduce distraction. I created https://bugs.openjdk.java.net/browse/JDK-8275506 and https://github.com/openjdk/jdk/pull/6004. I will merge that one. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 19 12:36:56 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 12:36:56 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 05:54:55 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/asm/codeBuffer.hpp line 369: > >> 367: // addresses in a sibling section. >> 368: >> 369: class CodeBuffer: public ResourceObj DEBUG_ONLY(COMMA private Scrubber) { > > Deriving from ResourceObj rather than the previous fakery seems good. I think the multiple-inheritance derivation from Scrubber could be removed, instead adding ~CodeBuffer to do the zapping. That was how it looked when I started this fix (and it was rebased out to the Scrubber class by JDK-8264207). I will not change it back in this fix as the multiple inheritance problem is not introduced here. Another reason is that the authors of JDK-8264207 must have thought it looked better the way it is now. Personally I do not know. > src/hotspot/share/memory/allocation.cpp line 154: > >> 152: >> 153: #ifdef ASSERT >> 154: thread_local ResourceObj::RecentAllocations ResourceObj::_recent_allocations; > > Don't use `thread_local`. See the style guide. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From coleenp at openjdk.java.net Tue Oct 19 12:44:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 19 Oct 2021 12:44:50 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 10:05:15 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). >> >> Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. >> >> Testing: tier1-3, jdk_jfr >> >> Thanks >> Markus >> >> PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > header Looks good Markus. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6001 From mgronlun at openjdk.java.net Tue Oct 19 12:53:51 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 12:53:51 GMT Subject: RFR: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" [v2] In-Reply-To: References: Message-ID: <4TQA0uU_CuXYg8_37BgSE4ltrZ_PjkYKVG5RAR8L2w8=.b7b0028c-437b-4134-bc2e-1d1a81d6adc2@github.com> On Tue, 19 Oct 2021 12:19:24 GMT, Erik Gahlin wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> header > > Marked as reviewed by egahlin (Reviewer). Thanks, @egahlin and @coleenp, for your quick reviews. I will proceed to integrate this to restore testing in the CI. ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From mgronlun at openjdk.java.net Tue Oct 19 13:03:57 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 13:03:57 GMT Subject: Integrated: 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: References: Message-ID: <6tkPfLd6OEyTujY4e03WWYA6RmCFUynq9Rfp7Sd69Vg=.90d78563-e326-48bd-8203-c9c961e0907f@github.com> On Tue, 19 Oct 2021 09:39:06 GMT, Markus Gr?nlund wrote: > Greetings, > > This fixes the issue seen in testing when accessing an oop as part of unloading (introduced with [JDK-8266936](https://bugs.openjdk.java.net/browse/JDK-8266936)). > > Instead, oop accesses will be done outside of unloading and the result, i.e the codesource attribute, will be cached and reused in the FinalizerEntry. > > Testing: tier1-3, jdk_jfr > > Thanks > Markus > > PS one effect of this is that classes that unload before they have allocated anything will not have a codesource attribute. This can be fixed by letting classes register with the table as part of class loading, instead of during allocation. I will follow-up with a separate change for that. This pull request has now been integrated. Changeset: 98ab4b03 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/98ab4b03b311dcd8374cbbb21a898298798750d6 Stats: 109 lines in 4 files changed: 64 ins; 44 del; 1 mod 8275445: RunThese30M.java failed "assert(ZAddress::is_marked(addr)) failed: Should be marked" Reviewed-by: egahlin, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/6001 From lkorinth at openjdk.java.net Tue Oct 19 13:06:57 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 13:06:57 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:01:10 GMT, Leo Korinth wrote: >> src/hotspot/share/memory/allocation.hpp line 398: >> >>> 396: class ResourceObj ALLOCATION_SUPER_CLASS_SPEC { >>> 397: public: >>> 398: enum allocation_type : uint8_t { STACK_OR_EMBEDDED, RESOURCE_AREA, C_HEAP, ARENA }; >> >> Consider adding an "empty" allocation-type, that indicates an entry in the RecentAllocations is unused. > > After thinking a bit, I will not add an "empty" value. It will make it harder to make functions "total" that matches on the enum, and the "empty" value does not really need to be reset in RecentAllocations. STACK_OR_EMBEDDED is kind of a nice neutral element "mempty" in my opinion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 19 13:06:56 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 13:06:56 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 06:12:07 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp line 398: > >> 396: class ResourceObj ALLOCATION_SUPER_CLASS_SPEC { >> 397: public: >> 398: enum allocation_type : uint8_t { STACK_OR_EMBEDDED, RESOURCE_AREA, C_HEAP, ARENA }; > > Consider adding an "empty" allocation-type, that indicates an entry in the RecentAllocations is unused. After thinking a bit, I will not add an "empty" value. It will make it harder to make functions "total" that matches on the enum, and the "empty" value does not really need to be reset in RecentAllocations. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 19 13:38:50 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 13:38:50 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 06:21:09 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp line 416: > >> 414: static const unsigned BufferSize = 5; >> 415: uintptr_t _begin[BufferSize]; >> 416: uintptr_t _past_end[BufferSize]; > > I think these should be `const void*` rather than `uintptr_t`. Why do you think it is better? Comparing integers might possibly be preferable from comparing pointers from *different* objects that is undefined if I remember correctly. Of course casting them to integers probably does not make it that much better defined, but it feels at least a bit better... I will change it if you still prefer pointer comparison. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 19 13:46:53 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 13:46:53 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 06:21:52 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/allocation.hpp line 414: > >> 412: // allocation is done in a recursive step. In that case an assert will trigger. >> 413: class RecentAllocations { >> 414: static const unsigned BufferSize = 5; > > "5" seems like an odd choice. What would you suggest? I could make it "2", but then a smaller code change (or compiler upgrade) would force us to change the size. Any size is quite arbitrary, I will update this number to your suggestion if you give me a suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lkorinth at openjdk.java.net Tue Oct 19 13:59:50 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Oct 2021 13:59:50 GMT Subject: RFR: 8269537: memset() is called after operator new [v3] In-Reply-To: References: Message-ID: <90ieb6LOCOVaQNJWtR4A--008sktDRtI3czSMeaK1dE=.563992aa-16ab-42de-a2e0-eede50eb4a20@github.com> On Thu, 7 Oct 2021 06:18:00 GMT, Kim Barrett wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a thread local buffer so that the compiler might reorder operator new. > > src/hotspot/share/memory/memRegion.hpp line 110: > >> 108: // A ResourceObj version of MemRegionClosure >> 109: >> 110: class MemRegionClosureRO: public ResourceObj { > > I think this class could be deleted entirely, with the only derived class (`DirtyCardToOopClosure`) instead deriving from ResourceObj. I agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From ayang at openjdk.java.net Tue Oct 19 14:46:52 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 19 Oct 2021 14:46:52 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From duke at openjdk.java.net Tue Oct 19 14:49:59 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 19 Oct 2021 14:49:59 GMT Subject: Integrated: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. This pull request has now been integrated. Changeset: a579483c Author: Andrey Turbanov Committer: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/a579483c88e94bdaa787d109e5ae204e7fb308c0 Stats: 26 lines in 7 files changed: 0 ins; 13 del; 13 mod 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Reviewed-by: sspitsyn, cjplummer, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From mgronlun at openjdk.java.net Tue Oct 19 16:24:12 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:12 GMT Subject: Integrated: 8275517: Off-by-one error in allocation Message-ID: Greetings (again), The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( Sorry for this inconvenience. Markus ------------- Commit messages: - Off-by-one error in allocation Changes: https://git.openjdk.java.net/jdk/pull/6018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275517 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6018/head:pull/6018 PR: https://git.openjdk.java.net/jdk/pull/6018 From tschatzl at openjdk.java.net Tue Oct 19 16:24:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 15:31:39 GMT, Markus Gr?nlund wrote: > Greetings (again), > > The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus Lgtm. Fingers crossed that this fixes the issues in CI. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6018 From mgronlun at openjdk.java.net Tue Oct 19 16:24:13 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: <5TmbJhfbi201gbA3Ap-SRVxaP5MrCFpUaRhTZsI1DO8=.053527b9-dde1-411e-9699-8a0bf0a23fca@github.com> On Tue, 19 Oct 2021 15:34:13 GMT, Thomas Schatzl wrote: >> Greetings (again), >> >> The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( >> >> Sorry for this inconvenience. >> >> Markus > > Lgtm. Fingers crossed that this fixes the issues in CI. Thanks @tschatzl for bringing this to attention, apologies for the inconvenience. ------------- PR: https://git.openjdk.java.net/jdk/pull/6018 From mgronlun at openjdk.java.net Tue Oct 19 16:24:13 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Oct 2021 16:24:13 GMT Subject: Integrated: 8275517: Off-by-one error in allocation In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 15:31:39 GMT, Markus Gr?nlund wrote: > Greetings (again), > > The quick fix for [JDK-8275445](https://bugs.openjdk.java.net/browse/JDK-8275445) includes an off-by-one error as part of the allocation. :-( > > Sorry for this inconvenience. > > Markus This pull request has now been integrated. Changeset: 99bf7dd8 Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/99bf7dd8ddac1b5870534af50c97bec554004248 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8275517: Off-by-one error in allocation Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/6018 From cjplummer at openjdk.java.net Tue Oct 19 20:47:55 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 20:47:55 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Mon, 18 Oct 2021 20:02:21 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the actions in handleAppResumeBreakpoint() are moved/deferred until >> doPendingTasks() runs. This is necessary because an event handler must not >> release handlerLock first and foremost because handlers are called while >> iterating the handler chain for an event type which is protected by handlerLock >> (see https://github.com/openjdk/jdk/pull/5805) >> >> The first commit delays the cleanup actions after leaving the loop in >> `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 >> test with the command >> >> >> make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 >> >> >> The second commit adds a new test that reproduces the deadlock when calling >> threadControl_resumeThread() while a thread is waiting in >> blockOnDebuggerSuspend(). >> >> The third commit contains the fix described above. With it the deadlocks >> cannot be reproduced anymore. >> >> The forth commit removes the diagnostic code introduced with the first commit again. >> >> The fix passed >> >> test/hotspot/jtreg/serviceability/jdwp >> test/jdk/com/sun/jdi >> test/hotspot/jtreg/vmTestbase/nsk/jdwp >> test/hotspot/jtreg/vmTestbase/nsk/jdi > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Call blockOnDebuggerSuspend() after setup of the resumer tracking. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 770: > 768: * handlerLock which has to be acquired before threadLock. > 769: */ > 770: debugMonitorExit(threadLock); I think we can avoid the exit here. threadLock was grabbed in `threadControl_onEventHandlerExit()`. It probably should be released before calling `doPendingTasks()`. My suggestion would be to first release it right after the `findThread()` call, and then in the `ei == EI_THREAD_END` block grab it again at the start of the block and release at the end of the block. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 771: > 769: */ > 770: debugMonitorExit(threadLock); > 771: eventHandler_lock(); /* for proper lock order */ "for proper lock order during eventHandler_createInternalThreadOnly() calls" src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 772: > 770: debugMonitorExit(threadLock); > 771: eventHandler_lock(); /* for proper lock order */ > 772: debugMonitorEnter(threadLock); Somewhere we need to mention that `trackAppResume()` exits with threadLock still being held, although with my recommended changes below this would no longer be the case. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 807: > 805: } > 806: > 807: eventHandler_unlock(); This is still a bit odd looking because we grabbed this lock for lock ordering purposes, but are now releasing it out of order. But it's starting to sink in with me that the root of our problem here is that lock order dictates grabbing handlerLock first, and we need to eventually wait on threadLock but with handlerLock released, which suggest the lock ordering is reversed. There is probably some design bug here that results in that, but I'd hate to mess with the ordering of these two locks to try to fix it. Maybe a 3rd lock would help (wait on some new lock instead of threadLock). We could grab that lock first in `doPendingTasks()`, and not have to exit `trackAppResume()` with threadLock held, but again this might be more risk than it is worth. So it we aren't going to change the lock ordering or introduce a 3rd lock, then my suggestion would be (after making the above suggested change to release threadLock before calling `threadControl_onEventHandlerExit()`) to move the locking and unlocking into `doPendingTasks()`. At the start of the `node->handlingAppResume` block, grab handlerLock and threadLock, and explain that handlerLock is being grabbed because trackAppResume() will (indirectly) try to grab it, and grabbing it before threadLock is necessary for lock ordering. Then grab threadLock and hold onto it until the end of the block. Between the `trackAppResume()` and `blockOnDebuggerSuspend()` calls, release handlerLock and explain that it will not be needed anymore, and has to be released before calling `blockOnDebuggerSuspend()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From iklam at openjdk.java.net Tue Oct 19 21:19:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Oct 2021 21:19:09 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: Message-ID: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> On Thu, 23 Sep 2021 15:24:47 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > 8271356: Invoke auto-advance on empty input after targeted list command Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. I would recommend making a prerequisite PR first: - Break the huge lines in those two files in the same way as TTYResources.java. Verify that TTYResources_ja.class, etc, are identical to the previous version. Integrate into openjdk. - Revert the changes of those two files in the current PR - Merge with the prerequisite PR - Add the new lines into those two files Thanks - Ioi ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Tue Oct 19 21:24:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 21:24:06 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. > > - Remove all APIs that take a user name > - Also removed PerfDataFile.getFile() methods that are unused > - Cleaned up the code that looks up the hsperfdata_xxx files > - Fix comments to explain what's happening > - Avoid using Matcher.reset which is not thread-safe > - Renamed confusing variables such as `userFilter` to make the code more readable > - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. > > Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java line 80: > 78: "^hsperfdata_[0-9]+(_[1-2]+)?$"; > 79: > 80: I don't understand why you thought it best to remove these and instead use hard coded references to these partterns. ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From cjplummer at openjdk.java.net Tue Oct 19 21:29:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 21:29:07 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:16:03 GMT, Ioi Lam wrote: > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From iklam at openjdk.java.net Tue Oct 19 21:45:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Oct 2021 21:45:07 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 21:17:57 GMT, Chris Plummer wrote: >> LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. >> >> The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. >> >> - Remove all APIs that take a user name >> - Also removed PerfDataFile.getFile() methods that are unused >> - Cleaned up the code that looks up the hsperfdata_xxx files >> - Fix comments to explain what's happening >> - Avoid using Matcher.reset which is not thread-safe >> - Renamed confusing variables such as `userFilter` to make the code more readable >> - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. >> >> Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). > > src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java line 80: > >> 78: "^hsperfdata_[0-9]+(_[1-2]+)?$"; >> 79: >> 80: > > I don't understand why you thought it best to remove these and instead use hard coded references to these partterns. I have two goals - these aren't used anywhere else, so it's better to at least move them from this file to LocalVmManager.java, where they are actually used. So you don't need to flip between two files. - the behavior is easier to understand if the string literals, comments, and the code that uses them are together. Note that the original code has plenty of comment that are rather useless if you want to know how the files are searched. ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From iklam at openjdk.java.net Tue Oct 19 21:55:05 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 19 Oct 2021 21:55:05 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:26:11 GMT, Chris Plummer wrote: > > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. > > I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. Sounds good to me, too. Just remember to file a bug to update the localized text. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Tue Oct 19 22:07:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 22:07:07 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. > > - Remove all APIs that take a user name > - Also removed PerfDataFile.getFile() methods that are unused > - Cleaned up the code that looks up the hsperfdata_xxx files > - Fix comments to explain what's happening > - Avoid using Matcher.reset which is not thread-safe > - Renamed confusing variables such as `userFilter` to make the code more readable > - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. > > Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 75: > 73: // 1.4.1 (or earlier?): the files are stored directly under {tmpdir}/ with > 74: // the following pattern. > 75: Pattern oldtmpFilePattern = Pattern.compile("^hsperfdata_[0-9]+(_[1-2]+)?$"); So this pattern optionally has `_` followed by a sequence of 1's and 2's at the end? Seems odd. src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 105: > 103: > 104: > 105: // 1.4.2 and later: Look for the files {tmpdir}/hsperfdata_{any_user_name}/[0-0]+ should be `[0-9]+` ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From cjplummer at openjdk.java.net Tue Oct 19 22:07:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 22:07:07 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 21:41:41 GMT, Ioi Lam wrote: >> src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java line 80: >> >>> 78: "^hsperfdata_[0-9]+(_[1-2]+)?$"; >>> 79: >>> 80: >> >> I don't understand why you thought it best to remove these and instead use hard coded references to these partterns. > > I have two goals > - these aren't used anywhere else, so it's better to at least move them from this file to LocalVmManager.java, where they are actually used. So you don't need to flip between two files. > - the behavior is easier to understand if the string literals, comments, and the code that uses them are together. > > Note that the original code has plenty of comment that are rather useless if you want to know how the files are searched. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From cjplummer at openjdk.java.net Tue Oct 19 22:08:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Oct 2021 22:08:07 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:52:14 GMT, Ioi Lam wrote: > > > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. > > > > > > I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > > Sounds good to me, too. Just remember to file a bug to update the localized text. The file is in an internal list that is suppose to be automatically checked to see what has changed since the last time we localized (it may not be done every release), so there should be no need for a CR. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From sspitsyn at openjdk.java.net Wed Oct 20 02:26:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 20 Oct 2021 02:26:10 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: <9nB_cwTM3coW0cRQYFJT8EZDtpCsWO-IP6f7rxDkcgw=.c9578e0b-0cee-49b4-816a-12e0ba1c30ca@github.com> On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. > > - Remove all APIs that take a user name > - Also removed PerfDataFile.getFile() methods that are unused > - Cleaned up the code that looks up the hsperfdata_xxx files > - Fix comments to explain what's happening > - Avoid using Matcher.reset which is not thread-safe > - Renamed confusing variables such as `userFilter` to make the code more readable > - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. > > Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). Hi Ioi, It looks good to me except the line 105 commented by Chris. I wonder how should this be tested to make sure there are no regressions. We have a little lack of knowledge in this area. I guess, we need the performance team to get involved into this review. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From duke at openjdk.java.net Wed Oct 20 03:06:00 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Wed, 20 Oct 2021 03:06:00 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: References: Message-ID: > This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. > > Notes on the patch: > > - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). > - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. > - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: 8271356: Revert non-transparent localization changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5290/files - new: https://git.openjdk.java.net/jdk/pull/5290/files/7c7764a5..5f896476 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=04-05 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5290/head:pull/5290 PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Wed Oct 20 03:07:14 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Wed, 20 Oct 2021 03:07:14 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 15:24:47 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > 8271356: Invoke auto-advance on empty input after targeted list command Yep, making those changes without reformatting the files was a big pain. I've reverted the changes for now as Chris suggested. Thanks for the input, Ioi and Chris. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From rrich at openjdk.java.net Wed Oct 20 06:54:05 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 20 Oct 2021 06:54:05 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Tue, 19 Oct 2021 20:17:59 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Call blockOnDebuggerSuspend() after setup of the resumer tracking. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 770: > >> 768: * handlerLock which has to be acquired before threadLock. >> 769: */ >> 770: debugMonitorExit(threadLock); > > I think we can avoid the exit here. threadLock was grabbed in `threadControl_onEventHandlerExit()`. It probably should be released before calling `doPendingTasks()`. My suggestion would be to first release it right after the `findThread()` call, and then in the `ei == EI_THREAD_END` block grab it again at the start of the block and release at the end of the block. But fields of ThreadNode "node" (aka "resumer") are read and also modified in `doPendingTasks()` and also in `threadControl_onEventHandlerExit()`. IMHO this needs to be synchronized with threadLock. At least it is not obvious that the synchronization is not needed. > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 771: > >> 769: */ >> 770: debugMonitorExit(threadLock); >> 771: eventHandler_lock(); /* for proper lock order */ > > "for proper lock order during eventHandler_createInternalThreadOnly() calls" Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 20 07:13:08 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 20 Oct 2021 07:13:08 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Tue, 19 Oct 2021 20:21:59 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Call blockOnDebuggerSuspend() after setup of the resumer tracking. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 772: > >> 770: debugMonitorExit(threadLock); >> 771: eventHandler_lock(); /* for proper lock order */ >> 772: debugMonitorEnter(threadLock); > > Somewhere we need to mention that `trackAppResume()` exits with threadLock still being held, although with my recommended changes below this would no longer be the case. If we cannot release `threadLock` before calling `doPendingTasks()` then I would suggest to comment that the caller of `trackAppResume()` is expected to hold `threadLock` and that it will be temporarily released. > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 807: > >> 805: } >> 806: >> 807: eventHandler_unlock(); > > This is still a bit odd looking because we grabbed this lock for lock ordering purposes, but are now releasing it out of order. But it's starting to sink in with me that the root of our problem here is that lock order dictates grabbing handlerLock first, and we need to eventually wait on threadLock but with handlerLock released, which suggest the lock ordering is reversed. There is probably some design bug here that results in that, but I'd hate to mess with the ordering of these two locks to try to fix it. Maybe a 3rd lock would help (wait on some new lock instead of threadLock). We could grab that lock first in `doPendingTasks()`, and not have to exit `trackAppResume()` with threadLock held, but again this might be more risk than it is worth. > > So it we aren't going to change the lock ordering or introduce a 3rd lock, then my suggestion would be (after making the above suggested change to release threadLock before calling `threadControl_onEventHandlerExit()`) to move the locking and unlocking into `doPendingTasks()`. At the start of the `node->handlingAppResume` block, grab handlerLock and threadLock, and explain that handlerLock is being grabbed because trackAppResume() will (indirectly) try to grab it, and grabbing it before threadLock is necessary for lock ordering. Then grab threadLock and hold onto it until the end of the block. Between the `trackAppResume()` and `blockOnDebuggerSuspend()` calls, release handlerLock and explain that it will not be needed anymore, and has to be released before calling `blockOnDebuggerSuspend()`. To me it does not look odd. I'd think it is ok to release locks out of order. IMHO adding a new third lock to be waited on in `doPendingTasks()` would make things even more complicated. Accesses to `suspendCount` are synchronized through `threadLock`. Waiting on that lock for change of `suspendCount` is straightforward really. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Oct 20 07:43:46 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 20 Oct 2021 07:43:46 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v8] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/0b0fef0e..53d6b9de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=06-07 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From lkorinth at openjdk.java.net Wed Oct 20 09:36:38 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Wed, 20 Oct 2021 09:36:38 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: > The basic problem is that we are relying on undefined behaviour, as documented in the code: > > // This whole business of passing information from ResourceObj::operator new > // to the ResourceObj constructor via fields in the "object" is technically UB. > // But it seems to work within the limitations of HotSpot usage (such as no > // multiple inheritance) with the compilers and compiler options we're using. > // And it gives some possibly useful checking for misuse of ResourceObj. > > > I am removing the undefined behaviour by passing the type of allocation through a thread local variable. > > This solution has some advantages: > 1) it is not UB > 2) it is simpler and easier to understand > 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) > 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. > > When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. > > I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. > > This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. > > I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. > > Testing on debug build tier1-3 > Testing on release build tier1 Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: review updates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5387/files - new: https://git.openjdk.java.net/jdk/pull/5387/files/c9d45906..640f2d83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=02-03 Stats: 11 lines in 4 files changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5387/head:pull/5387 PR: https://git.openjdk.java.net/jdk/pull/5387 From iignatyev at openjdk.java.net Wed Oct 20 18:42:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Oct 2021 18:42:25 GMT Subject: RFR: 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless Message-ID: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> Hi all, could you please review this tiny patch? from JBS: > serviceability/jvmti/GetObjectSizeClass.java doesn't ignore external flags (where it matters) and hence should not have been marked w/ vm.flagless Thanks, -- Igor ------------- Commit messages: - 8275666 Changes: https://git.openjdk.java.net/jdk/pull/6050/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6050&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275666 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6050.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6050/head:pull/6050 PR: https://git.openjdk.java.net/jdk/pull/6050 From lmesnik at openjdk.java.net Wed Oct 20 19:10:06 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 20 Oct 2021 19:10:06 GMT Subject: RFR: 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless In-Reply-To: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> References: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> Message-ID: On Wed, 20 Oct 2021 18:34:36 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > from JBS: >> serviceability/jvmti/GetObjectSizeClass.java doesn't ignore external flags (where it matters) and hence should not have been marked w/ vm.flagless > > Thanks, > -- Igor Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6050 From iignatyev at openjdk.java.net Wed Oct 20 19:28:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Oct 2021 19:28:08 GMT Subject: RFR: 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless In-Reply-To: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> References: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> Message-ID: On Wed, 20 Oct 2021 18:34:36 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > from JBS: >> serviceability/jvmti/GetObjectSizeClass.java doesn't ignore external flags (where it matters) and hence should not have been marked w/ vm.flagless > > Thanks, > -- Igor Thanks Leonid! ------------- PR: https://git.openjdk.java.net/jdk/pull/6050 From iignatyev at openjdk.java.net Wed Oct 20 19:28:08 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 20 Oct 2021 19:28:08 GMT Subject: Integrated: 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless In-Reply-To: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> References: <4ENAjqQbU6GGrJ6GMw9SaXRY8Pd7c7HUY1PyOj-OaHE=.6476e493-def7-4f1f-a8c2-c4c7f9837b4b@github.com> Message-ID: On Wed, 20 Oct 2021 18:34:36 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this tiny patch? > > from JBS: >> serviceability/jvmti/GetObjectSizeClass.java doesn't ignore external flags (where it matters) and hence should not have been marked w/ vm.flagless > > Thanks, > -- Igor This pull request has now been integrated. Changeset: cea3f010 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/cea3f010460c4b45e76bfac8a5b193c49fdd274a Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless Reviewed-by: lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/6050 From cjplummer at openjdk.java.net Thu Oct 21 03:27:12 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 21 Oct 2021 03:27:12 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Wed, 20 Oct 2021 06:50:51 GMT, Richard Reingruber wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 770: >> >>> 768: * handlerLock which has to be acquired before threadLock. >>> 769: */ >>> 770: debugMonitorExit(threadLock); >> >> I think we can avoid the exit here. threadLock was grabbed in `threadControl_onEventHandlerExit()`. It probably should be released before calling `doPendingTasks()`. My suggestion would be to first release it right after the `findThread()` call, and then in the `ei == EI_THREAD_END` block grab it again at the start of the block and release at the end of the block. > > But fields of ThreadNode "node" (aka "resumer") are read and also modified in `doPendingTasks()` and also in `threadControl_onEventHandlerExit()`. IMHO this needs to be synchronized with threadLock. At least it is not obvious that the synchronization is not needed. You already release threadLock temporarily in `trackAppResume()` and you used to release it temporarily in doPendingTasks(). I'm suggesting to instead release it in `threadControl_onEventHandlerExit()` before calling `doPendingTasks()` and then grab it again (after first grabbing the handlerLock) in `doPendingTasks()` before calling `trackAppResume()`. What can be modified in the ThreadNode during that time that you are concerned about? threadLock would still be held when `blockOnDebuggerSuspend()` is called. The only interesting lines that are currently executed while holding the threadLock but no longer would be are: 2193 if (node->handlingAppResume) { 2194 jthread resumer = node->thread; 2195 jthread resumee = getResumee(resumer); I don't think any of those can change, because only the currently executing thread can change them (when the Thread.resume() breakpoint is hit). The suspendCount is only meaningful when in `blockOnDebuggerSuspend()`, and we'll be under the threadLock by that point. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From cjplummer at openjdk.java.net Thu Oct 21 03:37:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 21 Oct 2021 03:37:09 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Thu, 21 Oct 2021 03:24:40 GMT, Chris Plummer wrote: >> But fields of ThreadNode "node" (aka "resumer") are read and also modified in `doPendingTasks()` and also in `threadControl_onEventHandlerExit()`. IMHO this needs to be synchronized with threadLock. At least it is not obvious that the synchronization is not needed. > > You already release threadLock temporarily in `trackAppResume()` and you used to release it temporarily in doPendingTasks(). I'm suggesting to instead release it in `threadControl_onEventHandlerExit()` before calling `doPendingTasks()` and then grab it again (after first grabbing the handlerLock) in `doPendingTasks()` before calling `trackAppResume()`. What can be modified in the ThreadNode during that time that you are concerned about? threadLock would still be held when `blockOnDebuggerSuspend()` is called. The only interesting lines that are currently executed while holding the threadLock but no longer would be are: > > 2193 if (node->handlingAppResume) { > 2194 jthread resumer = node->thread; > 2195 jthread resumee = getResumee(resumer); > > I don't think any of those can change, because only the currently executing thread can change them (when the Thread.resume() breakpoint is hit). > > The suspendCount is only meaningful when in `blockOnDebuggerSuspend()`, and we'll be under the threadLock by that point. BTW, normally I would not suggest less locking simply because I *thought* it might not be needed. However, you already temporarily release and then regrab the lock. This means there is a period of time where the locking is not needed. What I've suggested is to better define (and expand) that period of time so the locking can be made cleaner. I think the actual expansion of time where the lock would no longer be held is pretty small, with a well defined set of code being executed that to me does not appear to require the lock, and if it did require the lock, then probably releasing the lock in the first place is a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Thu Oct 21 08:04:04 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 21 Oct 2021 08:04:04 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Thu, 21 Oct 2021 03:34:30 GMT, Chris Plummer wrote: >> You already release threadLock temporarily in `trackAppResume()` and you used to release it temporarily in doPendingTasks(). I'm suggesting to instead release it in `threadControl_onEventHandlerExit()` before calling `doPendingTasks()` and then grab it again (after first grabbing the handlerLock) in `doPendingTasks()` before calling `trackAppResume()`. What can be modified in the ThreadNode during that time that you are concerned about? threadLock would still be held when `blockOnDebuggerSuspend()` is called. The only interesting lines that are currently executed while holding the threadLock but no longer would be are: >> >> 2193 if (node->handlingAppResume) { >> 2194 jthread resumer = node->thread; >> 2195 jthread resumee = getResumee(resumer); >> >> I don't think any of those can change, because only the currently executing thread can change them (when the Thread.resume() breakpoint is hit). >> >> The suspendCount is only meaningful when in `blockOnDebuggerSuspend()`, and we'll be under the threadLock by that point. > > BTW, normally I would not suggest less locking simply because I *thought* it might not be needed. However, you already temporarily release and then regrab the lock. This means there is a period of time where the locking is not needed. What I've suggested is to better define (and expand) that period of time so the locking can be made cleaner. I think the actual expansion of time where the lock would no longer be held is pretty small, with a well defined set of code being executed that to me does not appear to require the lock, and if it did require the lock, then probably releasing the lock in the first place is a bug. > move the locking and unlocking into doPendingTasks(). At the start of the > node->handlingAppResume block, grab handlerLock and threadLock, and explain > that handlerLock is being grabbed because trackAppResume() will (indirectly) > try to grab it, and grabbing it before threadLock is necessary for lock > ordering. Then grab threadLock and hold onto it until the end of the block. So threadLock would be released at the end of the new block that depends on node->handlingAppResume. After that block follow accesses to `pendingInterrupt` and `pendingStop` that would be unsynchronized then. I think they do need to be synchronized through threadLock though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From cjplummer at openjdk.java.net Thu Oct 21 15:08:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 21 Oct 2021 15:08:13 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: <9gQLDFunyfIwDK-uossixQS21BrfhgSA9Eg7m0drjr0=.c81b4ce0-2ad8-4826-a597-d056e6508588@github.com> On Thu, 21 Oct 2021 08:01:30 GMT, Richard Reingruber wrote: >> BTW, normally I would not suggest less locking simply because I *thought* it might not be needed. However, you already temporarily release and then regrab the lock. This means there is a period of time where the locking is not needed. What I've suggested is to better define (and expand) that period of time so the locking can be made cleaner. I think the actual expansion of time where the lock would no longer be held is pretty small, with a well defined set of code being executed that to me does not appear to require the lock, and if it did require the lock, then probably releasing the lock in the first place is a bug. > >> move the locking and unlocking into doPendingTasks(). At the start of the >> node->handlingAppResume block, grab handlerLock and threadLock, and explain >> that handlerLock is being grabbed because trackAppResume() will (indirectly) >> try to grab it, and grabbing it before threadLock is necessary for lock >> ordering. Then grab threadLock and hold onto it until the end of the block. > > So threadLock would be released at the end of the new block that depends on > node->handlingAppResume. After that block follow accesses to `pendingInterrupt` > and `pendingStop` that would be unsynchronized then. I think they do need to be > synchronized through threadLock though. If you are worried about another thread changing those fields after they have already been checked, then you can use the threadLock around them also. So you can grab threadLock before the `if (node->handlingAppResume)` and release after the `pendingInterrupt` and `pendingStop` references. I don't think it's really needed, because this is the only place where the flags are set false (and some action is taken when true), but there is no harm in holding the threadLock here, and it doesn't make the locking any more complicated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Thu Oct 21 19:37:41 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 21 Oct 2021 19:37:41 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v9] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Hoist locking from trackAppResume() up to it its caller doPendingTasks() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/53d6b9de..c884a76e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=07-08 Stats: 28 lines in 1 file changed: 12 ins; 12 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Thu Oct 21 19:42:12 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 21 Oct 2021 19:42:12 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: <9gQLDFunyfIwDK-uossixQS21BrfhgSA9Eg7m0drjr0=.c81b4ce0-2ad8-4826-a597-d056e6508588@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <9gQLDFunyfIwDK-uossixQS21BrfhgSA9Eg7m0drjr0=.c81b4ce0-2ad8-4826-a597-d056e6508588@github.com> Message-ID: On Thu, 21 Oct 2021 15:05:19 GMT, Chris Plummer wrote: >>> move the locking and unlocking into doPendingTasks(). At the start of the >>> node->handlingAppResume block, grab handlerLock and threadLock, and explain >>> that handlerLock is being grabbed because trackAppResume() will (indirectly) >>> try to grab it, and grabbing it before threadLock is necessary for lock >>> ordering. Then grab threadLock and hold onto it until the end of the block. >> >> So threadLock would be released at the end of the new block that depends on >> node->handlingAppResume. After that block follow accesses to `pendingInterrupt` >> and `pendingStop` that would be unsynchronized then. I think they do need to be >> synchronized through threadLock though. > > If you are worried about another thread changing those fields after they have already been checked, then you can use the threadLock around them also. So you can grab threadLock before the `if (node->handlingAppResume)` and release after the `pendingInterrupt` and `pendingStop` references. I don't think it's really needed, because this is the only place where the flags are set false (and some action is taken when true), but there is no harm in holding the threadLock here, and it doesn't make the locking any more complicated. I have hoisted the locking from `trackAppResume()` up to `doPendingTasks()` where it is more visible. The change in that form is sufficient to fix the deadlock issues. Would it be ok for you to do further enhancements in a follow-up RFE? ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From duke at openjdk.java.net Thu Oct 21 20:56:10 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 21 Oct 2021 20:56:10 GMT Subject: Integrated: 8275384: Change nested classes in jdk.jconsole to static nested classes In-Reply-To: References: Message-ID: <4cTMXijqakH6YAOlFudTWHEcmw0JLF4cyXJcYVNpnag=.946b7596-838b-43bd-a515-813db0454ce7@github.com> On Sat, 16 Oct 2021 20:32:43 GMT, Andrey Turbanov wrote: > Non-static classes hold a link to their parent classes, which can be avoided. This pull request has now been integrated. Changeset: 4e9dd4bd Author: Andrey Turbanov Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/4e9dd4bddb888717d774147d4ba1acecc750629c Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod 8275384: Change nested classes in jdk.jconsole to static nested classes Reviewed-by: alanb, sspitsyn, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/5974 From cjplummer at openjdk.java.net Fri Oct 22 04:07:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 22 Oct 2021 04:07:06 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <9gQLDFunyfIwDK-uossixQS21BrfhgSA9Eg7m0drjr0=.c81b4ce0-2ad8-4826-a597-d056e6508588@github.com> Message-ID: On Thu, 21 Oct 2021 19:38:41 GMT, Richard Reingruber wrote: >> If you are worried about another thread changing those fields after they have already been checked, then you can use the threadLock around them also. So you can grab threadLock before the `if (node->handlingAppResume)` and release after the `pendingInterrupt` and `pendingStop` references. I don't think it's really needed, because this is the only place where the flags are set false (and some action is taken when true), but there is no harm in holding the threadLock here, and it doesn't make the locking any more complicated. > > I have hoisted the locking from `trackAppResume()` up to `doPendingTasks()` > where it is more visible. The change in that form is sufficient to fix the > deadlock issues. Would it be ok for you to do further enhancements in a > follow-up RFE? Yes, an RFE is fine. The changes look good. I just added one suggestion to improve a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From cjplummer at openjdk.java.net Fri Oct 22 04:07:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 22 Oct 2021 04:07:07 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v9] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Thu, 21 Oct 2021 19:37:41 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the actions in handleAppResumeBreakpoint() are moved/deferred until >> doPendingTasks() runs. This is necessary because an event handler must not >> release handlerLock first and foremost because handlers are called while >> iterating the handler chain for an event type which is protected by handlerLock >> (see https://github.com/openjdk/jdk/pull/5805) >> >> The first commit delays the cleanup actions after leaving the loop in >> `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 >> test with the command >> >> >> make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 >> >> >> The second commit adds a new test that reproduces the deadlock when calling >> threadControl_resumeThread() while a thread is waiting in >> blockOnDebuggerSuspend(). >> >> The third commit contains the fix described above. With it the deadlocks >> cannot be reproduced anymore. >> >> The forth commit removes the diagnostic code introduced with the first commit again. >> >> The fix passed >> >> test/hotspot/jtreg/serviceability/jdwp >> test/jdk/com/sun/jdi >> test/hotspot/jtreg/vmTestbase/nsk/jdwp >> test/hotspot/jtreg/vmTestbase/nsk/jdi > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Hoist locking from trackAppResume() up to it its caller doPendingTasks() src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2212: > 2210: * handlerLock is not needed anymore. We release it before calling > 2211: * blockOnDebuggerSuspend() because it is required for resumes by the > 2212: * debugger so we cannot wait for that holding handlerLock. * handlerLock is not needed anymore. We must release it before calling * blockOnDebuggerSuspend() because it is required for resumes done by * the debugger. If resumee is currently suspended by the debugger, then * blockOnDebuggerSuspend() will block until a debugger resume is done. * If it blocks while holding the handlerLock, then the resume will deadlock. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Fri Oct 22 06:08:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 22 Oct 2021 06:08:11 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v7] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> <9gQLDFunyfIwDK-uossixQS21BrfhgSA9Eg7m0drjr0=.c81b4ce0-2ad8-4826-a597-d056e6508588@github.com> Message-ID: On Fri, 22 Oct 2021 04:04:13 GMT, Chris Plummer wrote: >> I have hoisted the locking from `trackAppResume()` up to `doPendingTasks()` >> where it is more visible. The change in that form is sufficient to fix the >> deadlock issues. Would it be ok for you to do further enhancements in a >> follow-up RFE? > > Yes, an RFE is fine. The changes look good. I just added one suggestion to improve a comment. Thanks. I've created https://bugs.openjdk.java.net/browse/JDK-8275764. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Fri Oct 22 06:21:37 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 22 Oct 2021 06:21:37 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v10] In-Reply-To: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: > This change fixes deadlocks described in the JBS-bug by: > > * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` > > * Notifying on `threadLock` in `threadControl_reset()` > > Also the actions in handleAppResumeBreakpoint() are moved/deferred until > doPendingTasks() runs. This is necessary because an event handler must not > release handlerLock first and foremost because handlers are called while > iterating the handler chain for an event type which is protected by handlerLock > (see https://github.com/openjdk/jdk/pull/5805) > > The first commit delays the cleanup actions after leaving the loop in > `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 > test with the command > > > make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 > > > The second commit adds a new test that reproduces the deadlock when calling > threadControl_resumeThread() while a thread is waiting in > blockOnDebuggerSuspend(). > > The third commit contains the fix described above. With it the deadlocks > cannot be reproduced anymore. > > The forth commit removes the diagnostic code introduced with the first commit again. > > The fix passed > > test/hotspot/jtreg/serviceability/jdwp > test/jdk/com/sun/jdi > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Improve comment as suggested by Chris. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/c884a76e..3383a236 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=08-09 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5849/head:pull/5849 PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Fri Oct 22 06:21:42 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 22 Oct 2021 06:21:42 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v9] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: <656YbjtDHlsBW2Ey4Q-Xwf5ow8EfylS4BVIubFkCV1s=.3d98936a-d780-42cc-8b63-4106d4c63d68@github.com> On Fri, 22 Oct 2021 04:02:04 GMT, Chris Plummer wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Hoist locking from trackAppResume() up to it its caller doPendingTasks() > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2212: > >> 2210: * handlerLock is not needed anymore. We release it before calling >> 2211: * blockOnDebuggerSuspend() because it is required for resumes by the >> 2212: * debugger so we cannot wait for that holding handlerLock. > > * handlerLock is not needed anymore. We must release it before calling > * blockOnDebuggerSuspend() because it is required for resumes done by > * the debugger. If resumee is currently suspended by the debugger, then > * blockOnDebuggerSuspend() will block until a debugger resume is done. > * If it blocks while holding the handlerLock, then the resume will deadlock. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From cjplummer at openjdk.java.net Fri Oct 22 17:52:11 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 22 Oct 2021 17:52:11 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v10] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Fri, 22 Oct 2021 06:21:37 GMT, Richard Reingruber wrote: >> This change fixes deadlocks described in the JBS-bug by: >> >> * Releasing `handlerLock` before waiting on `threadLock` in `blockOnDebuggerSuspend()` >> >> * Notifying on `threadLock` in `threadControl_reset()` >> >> Also the actions in handleAppResumeBreakpoint() are moved/deferred until >> doPendingTasks() runs. This is necessary because an event handler must not >> release handlerLock first and foremost because handlers are called while >> iterating the handler chain for an event type which is protected by handlerLock >> (see https://github.com/openjdk/jdk/pull/5805) >> >> The first commit delays the cleanup actions after leaving the loop in >> `debugLoop_run()`. It allows to reproduce the deadlock running the dispose003 >> test with the command >> >> >> make run-test TEST=test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/dispose/dispose003 >> >> >> The second commit adds a new test that reproduces the deadlock when calling >> threadControl_resumeThread() while a thread is waiting in >> blockOnDebuggerSuspend(). >> >> The third commit contains the fix described above. With it the deadlocks >> cannot be reproduced anymore. >> >> The forth commit removes the diagnostic code introduced with the first commit again. >> >> The fix passed >> >> test/hotspot/jtreg/serviceability/jdwp >> test/jdk/com/sun/jdi >> test/hotspot/jtreg/vmTestbase/nsk/jdwp >> test/hotspot/jtreg/vmTestbase/nsk/jdi > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment as suggested by Chris. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From duke at openjdk.java.net Sun Oct 24 23:05:07 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Sun, 24 Oct 2021 23:05:07 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:52:14 GMT, Ioi Lam wrote: >>> Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > >> > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > > Sounds good to me, too. Just remember to file a bug to update the localized text. Okay, looks like Skara still needs this to be marked as reviewed before I can integrate it. @iklam and @plummercj, would one or both of you be able to fulfill that requirement if no more changes are needed here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Mon Oct 25 02:02:06 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Oct 2021 02:02:06 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:52:14 GMT, Ioi Lam wrote: >>> Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > >> > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > > Sounds good to me, too. Just remember to file a bug to update the localized text. > Okay, looks like Skara still needs this to be marked as reviewed before I can integrate it. @iklam and @plummercj, would one or both of you be able to fulfill that requirement if no more changes are needed here? I just added some comments regarding a localization issue that needs to be addressed. Also, just a reminder that you need two reviews for anything hotspot related (which includes all serviceability support), although technically Skara will let you get away with just one. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Mon Oct 25 02:02:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Oct 2021 02:02:08 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 03:06:00 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > 8271356: Revert non-transparent localization changes src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java line 113: > 111: {"Deferring.", "Deferring {0}.\nIt will be set after the class is loaded."}, > 112: {"End of stack.", "End of stack."}, > 113: {"EOF", "EOF"}, I just realized that this entry is missing from the localization files. This is needed for correct functionality because a lookup will be done for "EOF", and nothing will be found. I'm not sure what happens in this case. Maybe an exception. I guess you could experiment by removing this entry from this file, and see what happens when "EOF" gets referenced during a listing. You should at least add an "EOF" line to the other localization files. I'm not sure what you should add for the translation. Maybe just keep the English version. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java line 266: > 264: {"repeat is on", "Repeat is on"}, > 265: {"repeat is off", "Repeat is off"}, > 266: {"repeat usage", "Usage: repeat "}, These entries also need to be added the the other localization files. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Mon Oct 25 02:49:03 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 25 Oct 2021 02:49:03 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: References: Message-ID: <7PWdDjC8NCpkZMblbtHNdeimzmV5nZc4FIFE2FZWxSc=.60b32376-e298-44c1-9efb-d6a1ea74e2c0@github.com> On Wed, 20 Oct 2021 03:06:00 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > 8271356: Revert non-transparent localization changes Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Mon Oct 25 02:56:47 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 25 Oct 2021 02:56:47 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v7] In-Reply-To: References: Message-ID: > This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. > > Notes on the patch: > > - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). > - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. > - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: Add explicit localization fallbacks to English ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5290/files - new: https://git.openjdk.java.net/jdk/pull/5290/files/5f896476..da4d3a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=05-06 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5290/head:pull/5290 PR: https://git.openjdk.java.net/jdk/pull/5290 From ddong at openjdk.java.net Mon Oct 25 06:45:00 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 25 Oct 2021 06:45:00 GMT Subject: RFR: 8275259: Add support for Java level DCmd [v2] In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Fri, 15 Oct 2021 10:58:29 GMT, Denghui Dong wrote: >> I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. >> >> At present, I have implemented a preliminary version. >> >> In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. >> >> - Executable interface >> Java diagnostic commands need to implement this interface, the interface only contains a simple method: >> >> /** >> * @param output the output when this executable is running >> */ >> void execute(PrintWriter output); >> >> >> - Add two annotations (@Command and @Parameter) to describe the command meta info >> >> - Use Factory API to register command, the following forms are supported >> >> @Command(name = "My.Echo", description = "Echo description") >> class Echo implements Executable { >> >> @Parameter(name = "text", ordinal=0, isMandatory = true) >> String text; >> >> @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") >> int repeat; >> >> @Override >> public void execute(PrintWriter out) { >> for (int i = 0 ; i < repeat; i++) { >> out.println(text); >> } >> } >> } >> >> Factory.register(Echo.class); >> >> >> >> Factory.register("My.Date", output -> { >> output.println(new Date()); >> }); >> >> >> - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. >> >> At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). >> >> In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. >> >> Any input is appreciated. >> >> Thanks, >> Denghui > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > print argument key if not found Seems no more comments on this issue, but I still think this is a useful feature and want it could be a standard feature. The following is my thought. The idea of ??this feature originally came from our internal Java agent that detects the misusage of Unsafe API. This agent can collect the call sites that allocate or free direct memory in the application(NMT could not do it IMO) to detect direct memory leaks. In the beginning, it just prints call sites, without any statistical function, it's hard to use. So we plan to use a way similar to jeprof (from jemalloc) to generate a report file that aggregates all useful information. During the implementation process, we found that we need a mechanism to notify the agent to generate reports. (Multiple unrelated dependent components in a Java application may require such a mechanism) The common practice is: a) Register a service port, triggered by an HTTP request b) Triggered by signal c) Generate reports periodically, or when the process exits But these three ways have certain problems. For a) we need to introduce a network component, will increase the complexity of implementation For b) we cannot pass parameters For c) some files that may never be used will be generated Essentially, this question is how to notify the application to do a certain task, or in other words, how do we issue a command to the application. Naturally, we think that `jcmd` can already issue some commands registered in VM to the application, why can't we extend to the java layer? This feature will be very useful for some lightweight tools, just like the scenario we encountered, to notify the tools to perform certain operations. In addition, this feature will also bring benefits to Java beginners. For example, at the beginning, beginners may not use advanced log components, but they will also encounter the need to output debug logs. They may write code like this: if (debug) { System.out.println("..."); } If developers can easily and dynamically control the value of `debug`, it's attractive. Factory.register("MyApp.flipDebug", out -> debug = !debug); jcmd MyApp.flipDebug I agree with what Erik said, we need to find applicable scenarios in some mainstream frameworks. After my preliminary investigation, I think we can apply this feature in the features of `health checks`, `graceful shutdown`, and `dynamic configuration updates`. But to be honest, these frameworks are very mature and stable, and for compatibility purposes, it's hard to let them use this extension. In terms of code maintainability, the implementation of this extension does not need to destroy the existing framework. The current implementation only extends the DCmd framework and provides several simple APIs for users to use. I think there will not be too many costs after it's stable. If this feature could become a standard feature, I will be the first user:) Best, Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From stuefe at openjdk.java.net Mon Oct 25 07:21:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 25 Oct 2021 07:21:02 GMT Subject: RFR: 8275259: Add support for Java level DCmd [v2] In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Fri, 15 Oct 2021 10:58:29 GMT, Denghui Dong wrote: >> I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week. >> >> At present, I have implemented a preliminary version. >> >> In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands. >> >> - Executable interface >> Java diagnostic commands need to implement this interface, the interface only contains a simple method: >> >> /** >> * @param output the output when this executable is running >> */ >> void execute(PrintWriter output); >> >> >> - Add two annotations (@Command and @Parameter) to describe the command meta info >> >> - Use Factory API to register command, the following forms are supported >> >> @Command(name = "My.Echo", description = "Echo description") >> class Echo implements Executable { >> >> @Parameter(name = "text", ordinal=0, isMandatory = true) >> String text; >> >> @Parameter(name = "repeat", isMandatory = true, defaultValue = "1") >> int repeat; >> >> @Override >> public void execute(PrintWriter out) { >> for (int i = 0 ; i < repeat; i++) { >> out.println(text); >> } >> } >> } >> >> Factory.register(Echo.class); >> >> >> >> Factory.register("My.Date", output -> { >> output.println(new Date()); >> }); >> >> >> - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked. >> >> At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.). >> >> In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being. >> >> Any input is appreciated. >> >> Thanks, >> Denghui > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > print argument key if not found Hi Denghui, as I wrote before, I am neutral on this. But I agree with @egahlin that this seems to be more on JEP level. A PR is not the right first step for this, and I am afraid you won't build much consensus here. Maybe discuss this first on the serviceability ML? Or on hotspot-dev? Kind Regards, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From ddong at openjdk.java.net Mon Oct 25 08:30:04 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 25 Oct 2021 08:30:04 GMT Subject: RFR: 8275259: Add support for Java level DCmd [v2] In-Reply-To: References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> Message-ID: On Mon, 25 Oct 2021 07:17:37 GMT, Thomas Stuefe wrote: > Hi Denghui, > > as I wrote before, I am neutral on this. But I agree with @egahlin that this seems to be more on JEP level. A PR is not the right first step for this, and I am afraid you won't build much consensus here. Maybe discuss this first on the serviceability ML? Or on hotspot-dev? > > Kind Regards, Thomas Okay, thanks! Will send an RFC discussion mail. ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From denghui.ddh at alibaba-inc.com Mon Oct 25 08:37:07 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 25 Oct 2021 16:37:07 +0800 Subject: =?UTF-8?B?UkZDOiBFeHRlbmQgRENtZChEaWFnbm9zdGljLUNvbW1hbmQpIGZyYW1ld29yayB0byBzdXBw?= =?UTF-8?B?b3J0IEphdmEgbGV2ZWwgRENtZA==?= Message-ID: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> Hi there! We'd like to discuss a proposal for extending the current DCmd framework to support Java level DCmd. At present, DCmd only allows the VM to register commands, which can be called through jcmd or JMX. It would be beneficial if the user could create their own commands. The idea of this extension originally came from our internal Java agent that detects the misusage of Unsafe API. This agent can collect the call sites that allocate or free direct memory in the application(NMT could not do it IMO) to detect direct memory leaks. In the beginning, it just prints all call sites, without any statistical function, it's hard to use. So we plan to use a way similar to jeprof (from jemalloc) to generate a report file that aggregates all useful information. During the implementation process, we found that we need a mechanism to notify the agent to generate reports. The common practice is: a) Register a service port, triggered by an HTTP request b) Triggered by signal c) Generate reports periodically, or when the process exits But these three ways have certain problems. For a) we need to introduce a network component, will increase the complexity of implementation For b) we cannot pass parameters For c) some files that may never be used will be generated Essentially, this question is how to notify the application to do a certain task, or in other words, how do we issue a command to the application. We believe that other Java developers will also encounter similar problems. (And sometimes there may be multiple unrelated dependent components in a Java application that require such a mechanism.) Naturally, we think that jcmd can already issue some commands registered in VM to the application, why can't we extend to the java level? This feature will be very useful for some lightweight tools, just like the scenario we encountered, to notify the tools to perform certain operations. In addition, this feature will also bring benefits to Java beginners. For example, in the beginning, beginners may not use advanced log components, but they will also encounter the need to output debug logs. They may write code like this: ``` if (debug) { System.out.println("..."); } ``` If developers can easily control the value of debug, it's attractive. Like this: ``` Factory.register("MyApp.flipDebug", out -> debug = !debug); jcmd MyApp.flipDebug ``` For mainstream framework, we can apply this feature to trigger some common activities, such as health checks, graceful shutdown, and dynamic configuration updates, But to be honest, these frameworks are very mature and stable, and for compatibility purposes, it's hard to let them use this extension. Comments welcome! Thanks, Denghui -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.java.net Mon Oct 25 12:59:24 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Oct 2021 12:59:24 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock Message-ID: The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. I tested this change with that patch though and it passes tier1-6, ------------- Commit messages: - 8275800: Redefinition leaks MethodData::_extra_data_lock Changes: https://git.openjdk.java.net/jdk/pull/6105/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6105&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275800 Stats: 17 lines in 2 files changed: 8 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6105/head:pull/6105 PR: https://git.openjdk.java.net/jdk/pull/6105 From cjplummer at openjdk.java.net Mon Oct 25 19:54:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Oct 2021 19:54:08 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: <7PWdDjC8NCpkZMblbtHNdeimzmV5nZc4FIFE2FZWxSc=.60b32376-e298-44c1-9efb-d6a1ea74e2c0@github.com> References: <7PWdDjC8NCpkZMblbtHNdeimzmV5nZc4FIFE2FZWxSc=.60b32376-e298-44c1-9efb-d6a1ea74e2c0@github.com> Message-ID: On Mon, 25 Oct 2021 02:45:52 GMT, Jakob Cornell wrote: > Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. Ok. That change looks good, but you need to update the copyright in those two files. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From dholmes at openjdk.java.net Mon Oct 25 21:40:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Oct 2021 21:40:40 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock In-Reply-To: References: Message-ID: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> On Mon, 25 Oct 2021 12:51:32 GMT, Coleen Phillimore wrote: > The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. > I tested this change with that patch though and it passes tier1-6, src/hotspot/share/oops/instanceKlass.cpp line 2692: > 2690: > 2691: // Called also by InstanceKlass::deallocate_contents > 2692: void InstanceKlass::release_C_heap_structures_internal() { Why do we have two different cleanup functions here? It seems overly subtle that `deallocate_contents` only calls `release_C_heap_structures_internal`, rather than `release_C_heap_structures`. And now the only difference is whether `constants()->release_C_heap_structures()` is called, it seems to me that distinction should perhaps be more explicit in the caller. ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Mon Oct 25 22:20:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Oct 2021 22:20:16 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock In-Reply-To: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> Message-ID: <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> On Mon, 25 Oct 2021 21:33:33 GMT, David Holmes wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > src/hotspot/share/oops/instanceKlass.cpp line 2692: > >> 2690: >> 2691: // Called also by InstanceKlass::deallocate_contents >> 2692: void InstanceKlass::release_C_heap_structures_internal() { > > Why do we have two different cleanup functions here? It seems overly subtle that `deallocate_contents` only calls `release_C_heap_structures_internal`, rather than `release_C_heap_structures`. And now the only difference is whether `constants()->release_C_heap_structures()` is called, it seems to me that distinction should perhaps be more explicit in the caller. // Can't release the constant pool here because the constant pool can be // deallocated separately from the InstanceKlass for default methods and // redefine classes. Because of this comment. We have two ways that we can get to ConstantPool::deallocate_contents. We don't have two ways to get to the Method::deallocate_contents. The deallocate list contains unloaded/unattached Methods (from the relocator for jsr/ret), scratch classes from redefinition, fully formed constant pools from default methods, or fully formed InstanceKlass from classfile parsing errors or class definition errors. Only the constant pool case should be separated out in deallocate_contents, which is why it's excluded. ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Mon Oct 25 22:20:17 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Oct 2021 22:20:17 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock In-Reply-To: <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> Message-ID: On Mon, 25 Oct 2021 22:16:05 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 2692: >> >>> 2690: >>> 2691: // Called also by InstanceKlass::deallocate_contents >>> 2692: void InstanceKlass::release_C_heap_structures_internal() { >> >> Why do we have two different cleanup functions here? It seems overly subtle that `deallocate_contents` only calls `release_C_heap_structures_internal`, rather than `release_C_heap_structures`. And now the only difference is whether `constants()->release_C_heap_structures()` is called, it seems to me that distinction should perhaps be more explicit in the caller. > > // Can't release the constant pool here because the constant pool can be > // deallocated separately from the InstanceKlass for default methods and > // redefine classes. > > Because of this comment. We have two ways that we can get to ConstantPool::deallocate_contents. We don't have two ways to get to the Method::deallocate_contents. > > The deallocate list contains unloaded/unattached Methods (from the relocator for jsr/ret), scratch classes from redefinition, fully formed constant pools from default methods, or fully formed InstanceKlass from classfile parsing errors or class definition errors. > > Only the constant pool case should be separated out in deallocate_contents, which is why it's excluded. Is the suggestion to have a default parameter to free CHEAP structures that's false for deallocate_contents? ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From duke at openjdk.java.net Mon Oct 25 22:21:54 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 25 Oct 2021 22:21:54 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: > This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. > > Notes on the patch: > > - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). > - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. > - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: Restore update of copyright messages in resource files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5290/files - new: https://git.openjdk.java.net/jdk/pull/5290/files/da4d3a18..f5539997 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5290&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5290/head:pull/5290 PR: https://git.openjdk.java.net/jdk/pull/5290 From coleenp at openjdk.java.net Mon Oct 25 22:49:39 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Oct 2021 22:49:39 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: Message-ID: > The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. > I tested this change with that patch though and it passes tier1-6, Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add parameter to release_C_heap_structures. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6105/files - new: https://git.openjdk.java.net/jdk/pull/6105/files/09b9bfcb..22b38b03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6105&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6105&range=00-01 Stats: 22 lines in 4 files changed: 4 ins; 10 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6105/head:pull/6105 PR: https://git.openjdk.java.net/jdk/pull/6105 From dholmes at openjdk.java.net Mon Oct 25 22:54:14 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 25 Oct 2021 22:54:14 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> Message-ID: On Mon, 25 Oct 2021 22:17:33 GMT, Coleen Phillimore wrote: >> // Can't release the constant pool here because the constant pool can be >> // deallocated separately from the InstanceKlass for default methods and >> // redefine classes. >> >> Because of this comment. We have two ways that we can get to ConstantPool::deallocate_contents. We don't have two ways to get to the Method::deallocate_contents. >> >> The deallocate list contains unloaded/unattached Methods (from the relocator for jsr/ret), scratch classes from redefinition, fully formed constant pools from default methods, or fully formed InstanceKlass from classfile parsing errors or class definition errors. >> >> Only the constant pool case should be separated out in deallocate_contents, which is why it's excluded. > > Is the suggestion to have a default parameter to free CHEAP structures that's false for deallocate_contents? > I'm not really sure it's an improvement because I have to have an extra parameter to Klass::release_C_heap_structures that's unused. That is one option but I was thinking perhaps remove `constants()->release_C_heap_structures()` from `instanceKlass::release_C_heap_structures()` and have the callers that should remove the CP call `ik->constants()->release_C_heap_structures()` directly? Or perhaps just change this comment: // Release C heap allocated data that this points to, which includes // reference counting symbol names. release_C_heap_structures_internal(); to ` // reference counting symbol names, but excludes the constant pool.` ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From sspitsyn at openjdk.java.net Mon Oct 25 23:00:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 25 Oct 2021 23:00:13 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> Message-ID: On Mon, 25 Oct 2021 22:51:37 GMT, David Holmes wrote: >> Is the suggestion to have a default parameter to free CHEAP structures that's false for deallocate_contents? >> I'm not really sure it's an improvement because I have to have an extra parameter to Klass::release_C_heap_structures that's unused. > > That is one option but I was thinking perhaps remove `constants()->release_C_heap_structures()` from `instanceKlass::release_C_heap_structures()` and have the callers that should remove the CP call `ik->constants()->release_C_heap_structures()` directly? > Or perhaps just change this comment: > > > // Release C heap allocated data that this points to, which includes > // reference counting symbol names. > release_C_heap_structures_internal(); > > > to > > ` // reference counting symbol names, but excludes the constant pool.` Yes, I think that combining release_C_heap_structures and release_C_heap_structures_internal into single release_C_heap_structures with a default parameter will simplify code a little bit. But I'm not sure it is that important and would leave it for you to decide. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From sspitsyn at openjdk.java.net Mon Oct 25 23:13:14 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 25 Oct 2021 23:13:14 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:49:39 GMT, Coleen Phillimore wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add parameter to release_C_heap_structures. Coleen, It looks good to me. Thanks, Serguei src/hotspot/share/oops/instanceKlass.cpp line 2693: > 2691: Klass::release_C_heap_structures(); > 2692: if (release_constant_pool) { > 2693: constants()->release_C_heap_structures(); Just wanted to note that the order of de-allocations has been changed with this fix. It should not be important though. To be fully safe this deallocation can be moved to the end of `release_C_heap_structures`. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6105 From sspitsyn at openjdk.java.net Mon Oct 25 23:24:11 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 25 Oct 2021 23:24:11 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> Message-ID: <7Xnvst8kX4nfCI_iHxLYpd7t2cZMR2qd6SJaXEeZd0M=.f1f7f120-05f4-4750-8907-79af6018f59f@github.com> On Mon, 25 Oct 2021 22:57:35 GMT, Serguei Spitsyn wrote: >> That is one option but I was thinking perhaps remove `constants()->release_C_heap_structures()` from `instanceKlass::release_C_heap_structures()` and have the callers that should remove the CP call `ik->constants()->release_C_heap_structures()` directly? >> Or perhaps just change this comment: >> >> >> // Release C heap allocated data that this points to, which includes >> // reference counting symbol names. >> release_C_heap_structures_internal(); >> >> >> to >> >> ` // reference counting symbol names, but excludes the constant pool.` > > Yes, I think that combining release_C_heap_structures and release_C_heap_structures_internal into single release_C_heap_structures with a default parameter will simplify code a little bit. But I'm not sure it is that important and would leave it for you to decide. :) I did not see the last comment from David when added mine. In fact, I like the David's suggestion to call `ik->constants()->release_C_heap_structures()` directly. It looks more simple to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From cjplummer at openjdk.java.net Tue Oct 26 07:07:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 26 Oct 2021 07:07:13 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: <_2c5AOGbxGg6dEa9zaUtnhR94Uzsvw_eWnjwUqsFlqo=.f8a31360-cb45-40db-8dd3-cfe8ebb507c4@github.com> On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Restore update of copyright messages in resource files Looks good. You still need one more reviewer. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5290 From kevinw at openjdk.java.net Tue Oct 26 07:51:12 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 26 Oct 2021 07:51:12 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 04:17:25 GMT, Ioi Lam wrote: > LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs owned by a specific user. No one uses these APIs, and they don't work anyway. > > The current code is very confusing to look at. Since we're likely to change code in this area for further container support, it's better to clean up the code now. > > - Remove all APIs that take a user name > - Also removed PerfDataFile.getFile() methods that are unused > - Cleaned up the code that looks up the hsperfdata_xxx files > - Fix comments to explain what's happening > - Avoid using Matcher.reset which is not thread-safe > - Renamed confusing variables such as `userFilter` to make the code more readable > - LocalVmManager.activeVms() probably doesn't need to be synchronized, but I kept it anyway to avoid unnecessary risks. > > Testing with Oracle CI: tiers1-4, plus hs-tier5-rt (which tests containers and have extensive use of the management tools). Nice cleanup - although was it not better for PerfDataFile.java to "own" the definitions of what a perfdata filename looks like? That might be what Chris was hinting at. There isn't really that _much_ flipping between two files. 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From coleenp at openjdk.java.net Tue Oct 26 11:37:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Oct 2021 11:37:11 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v2] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 23:09:03 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add parameter to release_C_heap_structures. > > src/hotspot/share/oops/instanceKlass.cpp line 2693: > >> 2691: Klass::release_C_heap_structures(); >> 2692: if (release_constant_pool) { >> 2693: constants()->release_C_heap_structures(); > > Just wanted to note that the order of de-allocations has been changed with this fix. It should not be important though. To be fully safe this deallocation can be moved to the end of `release_C_heap_structures`. It shouldn't make a difference but to be perfectly conservative, I'll move it to the end of the function. Thank you for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Tue Oct 26 11:43:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Oct 2021 11:43:42 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3] In-Reply-To: References: Message-ID: > The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. > I tested this change with that patch though and it passes tier1-6, Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Move constant pool release_C_heap_structures to the end. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6105/files - new: https://git.openjdk.java.net/jdk/pull/6105/files/22b38b03..4b52907f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6105&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6105&range=01-02 Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6105.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6105/head:pull/6105 PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Tue Oct 26 11:47:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 26 Oct 2021 11:47:18 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3] In-Reply-To: <7Xnvst8kX4nfCI_iHxLYpd7t2cZMR2qd6SJaXEeZd0M=.f1f7f120-05f4-4750-8907-79af6018f59f@github.com> References: <8vVneUUEGRU697sJgAYHWcqguc_1cZnxtlchPr8npiE=.d4099019-f0da-428e-9293-a4fd1a6237e4@github.com> <1UcQ7ZQtc-WXG46d96s1oxGWTkdot8jdy3bUEVgQAYw=.a3356dab-3c11-478e-a11d-9000064f5aeb@github.com> <7Xnvst8kX4nfCI_iHxLYpd7t2cZMR2qd6SJaXEeZd0M=.f1f7f120-05f4-4750-8907-79af6018f59f@github.com> Message-ID: On Mon, 25 Oct 2021 23:21:02 GMT, Serguei Spitsyn wrote: >> Yes, I think that combining release_C_heap_structures and release_C_heap_structures_internal into single release_C_heap_structures with a default parameter will simplify code a little bit. But I'm not sure it is that important and would leave it for you to decide. :) > > I did not see the last comment from David when added mine. In fact, I like the David's suggestion to call `ik->constants()->release_C_heap_structures()` directly. It looks more simple to me. I'd prefer that the callers do NOT release the constant pool CHeap structures directly. The main caller, during class unloading has the InstanceKlass as a handle to delete and it would be really easy to miss the constant pool case. The constant pool is contained by the InstanceKlass in this case. Deallocate_contents is the only exception for the exceptional case where we have added the InstanceKlass to the deallocate list. ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From sspitsyn at openjdk.java.net Tue Oct 26 16:54:10 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 26 Oct 2021 16:54:10 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 11:43:42 GMT, Coleen Phillimore wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move constant pool release_C_heap_structures to the end. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From duke at openjdk.java.net Tue Oct 26 17:59:17 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Tue, 26 Oct 2021 17:59:17 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v5] In-Reply-To: References: <-ellS8aoa3ECYnwVZoIcos6OTVqXkbPQ4tTjhVK5MUM=.4c17cc7b-5830-4055-bbdb-b086229187f1@github.com> Message-ID: On Tue, 19 Oct 2021 21:52:14 GMT, Ioi Lam wrote: >>> Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > >> > Hi Jacob, this is not your fault, but the "zz help text" in the Chinese and Japanese versions are in a single huge line. This makes it impossible to see what you have changed in the GitHub diffs, and impossible to tell whether you made any typos in the process. >> >> I'd suggest you just undo the change. As mentioned earlier, localization is not your responsibility, and this lack of localization won't cause jdb to not run properly. It will just be missing some help text. > > Sounds good to me, too. Just remember to file a bug to update the localized text. Thanks Chris. @iklam, would you be able to review these changes again? ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From iklam at openjdk.java.net Tue Oct 26 19:13:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 26 Oct 2021 19:13:23 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Restore update of copyright messages in resource files LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5290 From dholmes at openjdk.java.net Wed Oct 27 00:29:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 27 Oct 2021 00:29:08 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 11:43:42 GMT, Coleen Phillimore wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move constant pool release_C_heap_structures to the end. Updates look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Wed Oct 27 12:12:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Oct 2021 12:12:18 GMT Subject: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 11:43:42 GMT, Coleen Phillimore wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Move constant pool release_C_heap_structures to the end. Thanks David and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From coleenp at openjdk.java.net Wed Oct 27 12:12:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Oct 2021 12:12:18 GMT Subject: Integrated: 8275800: Redefinition leaks MethodData::_extra_data_lock In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 12:51:32 GMT, Coleen Phillimore wrote: > The Mutex destructor isn't called for the MDO lock. We found this leak with crashes for the patch to print all mutex locks on error, which is now withdrawn. It was easily reproduced with that patch. It is not easily reproduced otherwise. > I tested this change with that patch though and it passes tier1-6, This pull request has now been integrated. Changeset: 40606021 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/40606021ee6b7d18674e36b3f6249f1ca8a7647e Stats: 35 lines in 5 files changed: 11 ins; 16 del; 8 mod 8275800: Redefinition leaks MethodData::_extra_data_lock Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6105 From amenkov at openjdk.java.net Wed Oct 27 22:12:13 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Oct 2021 22:12:13 GMT Subject: RFR: 8274621: NullPointerException because listenAddress[0] is null In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). > The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". > Also updated javadoc to reflect actual behavior. Ping. Need 2nd reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/5830 From amenkov at openjdk.java.net Wed Oct 27 22:12:14 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Oct 2021 22:12:14 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) Ping. Need 2nd reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From cjplummer at openjdk.java.net Wed Oct 27 23:12:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Oct 2021 23:12:13 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) Marked as reviewed by cjplummer (Reviewer). Actually revoking my review for the moment. Do we have any tests that currently test the default PerfMaxStringConstLength, and this change could be subverting the test by making it so the length is never exceeded? ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From duke at openjdk.java.net Thu Oct 28 00:18:13 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Thu, 28 Oct 2021 00:18:13 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: References: <7PWdDjC8NCpkZMblbtHNdeimzmV5nZc4FIFE2FZWxSc=.60b32376-e298-44c1-9efb-d6a1ea74e2c0@github.com> Message-ID: <6BM8UP5Og3Jk94cemcwuQlJrl5s3epmWScqieJlGlQ8=.8635bd02-9a0e-4867-a67f-28d82dfc9149@github.com> On Mon, 25 Oct 2021 19:50:54 GMT, Chris Plummer wrote: >> Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. > >> Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. > > Ok. That change looks good, but you need to update the copyright in those two files. @plummercj Looks like this is all ready to go then. Would you be willing to sponsor it for integration? ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From lmesnik at openjdk.java.net Thu Oct 28 01:37:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 28 Oct 2021 01:37:09 GMT Subject: RFR: 8274621: NullPointerException because listenAddress[0] is null In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). > The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". > Also updated javadoc to reflect actual behavior. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5830 From magnus.ihse.bursie at oracle.com Thu Oct 28 07:48:28 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Oct 2021 09:48:28 +0200 Subject: kludgeMantis is no longer needed? Message-ID: I noticed the following piece of code in src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java: if(jvm_name.stringValue().indexOf("HotSpot") >= 0) { if(jvm_version.stringValue().startsWith("1.4.2")) { kludgeMantis(map, args); } } It looks like there's some room for cleaning out old cruft here... /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.java.net Thu Oct 28 13:11:21 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 28 Oct 2021 13:11:21 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Message-ID: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) ------------- Commit messages: - 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Changes: https://git.openjdk.java.net/jdk/pull/6156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275735 Stats: 104 lines in 6 files changed: 0 ins; 100 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6156/head:pull/6156 PR: https://git.openjdk.java.net/jdk/pull/6156 From hseigel at openjdk.java.net Thu Oct 28 14:07:11 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 28 Oct 2021 14:07:11 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote: > Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. > > Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) The changes look good. Thanks for doing this. Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6156 From sgehwolf at openjdk.java.net Thu Oct 28 14:11:09 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 28 Oct 2021 14:11:09 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 14:04:15 GMT, Harold Seigel wrote: > The changes look good. Thanks for doing this. Harold Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6156 From cjplummer at openjdk.java.net Thu Oct 28 15:30:24 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 28 Oct 2021 15:30:24 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6] In-Reply-To: References: <7PWdDjC8NCpkZMblbtHNdeimzmV5nZc4FIFE2FZWxSc=.60b32376-e298-44c1-9efb-d6a1ea74e2c0@github.com> Message-ID: On Mon, 25 Oct 2021 19:50:54 GMT, Chris Plummer wrote: >> Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. > >> Based on my local testing it appears the localization system falls back to the English values when entries are missing, so it appears the current behavior does already match what you've suggested. However, I don't understand the mechanism that implements this fallback handling, so I'm not sure the behavior would be consistent across environments. At least for now I'll add those entries back with the English translations copied, since that seems better. > > Ok. That change looks good, but you need to update the copyright in those two files. > @plummercj Looks like this is all ready to go then. Would you be willing to sponsor it for integration? Yes. I'm doing some testing with our CI now. I'll integrate once that is done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From mchung at openjdk.java.net Thu Oct 28 16:09:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Oct 2021 16:09:09 GMT Subject: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) In-Reply-To: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> References: <7ZPXxcvf9coOZQFefQf8GQAUgskWHL1dvQkCknWUBUs=.4013d956-3ef7-4f40-8c4f-c0c8578fdae0@github.com> Message-ID: On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote: > Please review this change to remove some API which no longer works as expected as recent OCI runtimes start to drop support for `--kernel-memory` switch. See the bug for references. This part of the API is not present in hotspot code. > > Testing: Container tests (cgroup v1) on Linux x86_64 (all pass) Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6156 From chris.plummer at oracle.com Thu Oct 28 19:36:49 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 28 Oct 2021 12:36:49 -0700 Subject: kludgeMantis is no longer needed? In-Reply-To: References: Message-ID: <5236d6da-6ec0-6292-26ca-0426d3a61d10@oracle.com> An HTML attachment was scrubbed... URL: From cjplummer at openjdk.java.net Thu Oct 28 19:41:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 28 Oct 2021 19:41:09 GMT Subject: RFR: 8274621: NullPointerException because listenAddress[0] is null In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). > The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". > Also updated javadoc to reflect actual behavior. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5830 From amenkov at openjdk.java.net Thu Oct 28 21:55:13 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 28 Oct 2021 21:55:13 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 23:09:09 GMT, Chris Plummer wrote: > Actually revoking my review for the moment. Do we have any tests that currently test the default PerfMaxStringConstLength, and this change could be subverting the test by making it so the length is never exceeded? We don't have any test for PerfMaxStringConstLength. I think we can fix the issue by using LingeredApp.startAppExactJvmOpts instead of LingeredApp.startApp. I the case test VM options are not added to target app and command line contains only specified options. It should be ok as we test only jps functionality. I don't have strong opinion which way is better. ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From kevinw at openjdk.java.net Fri Oct 29 11:37:28 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 29 Oct 2021 11:37:28 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Message-ID: Remove a specific test which invokes jps on a fictional process, and can timeout and fail. Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values. ------------- Commit messages: - Add bug ref in existing test - 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Changes: https://git.openjdk.java.net/jdk/pull/6170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276139 Stats: 61 lines in 3 files changed: 14 ins; 46 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6170/head:pull/6170 PR: https://git.openjdk.java.net/jdk/pull/6170 From jiefu at openjdk.java.net Fri Oct 29 11:59:13 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 29 Oct 2021 11:59:13 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test In-Reply-To: References: Message-ID: <9u_beVnrmWNO2IkBNboeshlNyJF0YkP0NXTrLwz3O_s=.5122c6da-c0bb-443b-beb2-5ee4b66a7baf@github.com> On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls wrote: > Remove a specific test which invokes jps on a fictional process, and can timeout and fail. > Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values. TestJpsHostName.java works fine on our test machines. Do you have any idea why it gets timeout on your machines? Or how can I reproduce the timeout situation? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/6170 From kevinw at openjdk.java.net Fri Oct 29 13:37:15 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 29 Oct 2021 13:37:15 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test In-Reply-To: References: Message-ID: <0rL4PHAW8WOs-XaP90g6H2IVXMMPGHqy0w1h9irWuaA=.13e35b58-a5ac-4dc1-aaa6-dece78c4e827@github.com> On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls wrote: > Remove a specific test which invokes jps on a fictional process, and can timeout and fail. > Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values. Hi, The timeout is interesting, but not _very_ interesting... 8-) My laptop fails quickly, with Linux under WSL, jps 12345 shows: RMI Registry not available at 12345:1099 Exception creating connection to: 12345; nested exception is: java.net.SocketException: Network is unreachable (connect failed) ..and strace: 22089 connect(13, {sa_family=AF_INET6, sin6_port=htons(1099), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable) That is not slow, although the test has already done what it needs to do (accept a numeric id) before it looks at the network. But a different machine takes a long time, strace shows: 8384 connect(6, {sa_family=AF_INET6, sin6_port=htons(1099), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 ..and we take 2 minutes+ to fail. The test times out and is called a failure by jtreg. ipv6 is kind of interesting as I'm not knowingly using it, but it is available on the interfaces in both cases. That slow run passes if jtreg has e.g. -timeout argument... It needs 5m27s to pass here. I have seen similar timings in the mach5 CI system. 20074 connect(6, {sa_family=AF_INET6, sin6_port=htons(37266), inet_pton(AF_INET6, "::ffff:0.0.48.57", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 ...lots of time... 20074 <... connect resumed> ) = -1 ETIMEDOUT (Connection timed out) No doubt these could be made to behave differently. But as we have an existing test which does what is needed, and avoids network unpredictability, I think that's the right move here. ------------- PR: https://git.openjdk.java.net/jdk/pull/6170 From jiefu at openjdk.java.net Fri Oct 29 13:55:18 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 29 Oct 2021 13:55:18 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls wrote: > Remove a specific test which invokes jps on a fictional process, and can timeout and fail. > Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values. LGTM Thanks for your explanation. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6170 From jiefu at openjdk.java.net Fri Oct 29 13:58:15 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 29 Oct 2021 13:58:15 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 11:29:32 GMT, Kevin Walls wrote: > Remove a specific test which invokes jps on a fictional process, and can timeout and fail. > Instead, add to the patterns used in open/test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java which will perform the same test, that we can create a HostIdentifier using numeric values. By the way, you will also backport it to jdk11u, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/6170 From duke at openjdk.java.net Fri Oct 29 17:53:17 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Fri, 29 Oct 2021 17:53:17 GMT Subject: Integrated: 8271356: Modify jdb to treat an empty command as a repeat of the previous command In-Reply-To: References: Message-ID: On Sat, 28 Aug 2021 05:48:47 GMT, Jakob Cornell wrote: > This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. > > Notes on the patch: > > - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). > - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. > - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. This pull request has now been integrated. Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 Stats: 560 lines in 10 files changed: 517 ins; 6 del; 37 mod 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From amenkov at openjdk.java.net Fri Oct 29 21:41:24 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 29 Oct 2021 21:41:24 GMT Subject: Integrated: 8274621: NullPointerException because listenAddress[0] is null In-Reply-To: References: Message-ID: <8xHfpmOmlD722ZNZmGYMM-BfkPonw0bHhU3zFBLRo3o=.a3e9c061-fdc2-4fe1-a956-0b138918d022@github.com> On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not updated). > The fix keeps existing functionality as is (as we have this behavior for a long time and we have tests which expect STDERR output), but adds synchronization to avoid calling predicate after previous call returned "true". > Also updated javadoc to reflect actual behavior. This pull request has now been integrated. Changeset: 5bbc8d3c Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 Stats: 14 lines in 1 file changed: 4 ins; 0 del; 10 mod 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5830 From dcubed at openjdk.java.net Fri Oct 29 22:19:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 29 Oct 2021 22:19:12 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> Message-ID: On Sun, 17 Oct 2021 12:45:59 GMT, David Holmes wrote: >> I modeled the new check after the existing: >> >> >> bool Thread::is_JavaThread_protected(const JavaThread* p) { >> >> >> which is also a static function. > > While the name is somewhat ungainly - and unnecessarily detailed given `is_JavaThread_protected` has a similar constraint - it should be a static function as given because it must only be called on the current thread, and an instance method would give the false impression that it could be called on any thread. > > That said it should be possible to write that code block only once and reuse it. And the name as I said is somewhat ungainly. You could even have: > > > static bool is_JavaThread_protected(const JavaThread* p, bool checkTLHOnly = false) { I'm checking out adding the `checkTLHOnly` param to `is_JavaThread_protected()` and replacing `is_JavaThread_protected_by_my_ThreadsList()` calls with calls to the updated function. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Oct 29 22:43:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 29 Oct 2021 22:43:14 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <3crX86JFPUtROcHPQS5QT-E6d8r31nlYWRGGIL95Sms=.70968898-84fe-4185-ad1f-b3f9e05e3731@github.com> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> Message-ID: On Sun, 17 Oct 2021 12:52:15 GMT, David Holmes wrote: >> On rereading all of these comments and the current baseline code, I have >> to clarify one thing: >> >> There is a minor change in behavior caused by switching from a >> `ThreadsListHandle::includes()` check to a `JavaThread::is_exiting()` >> check. The `JavaThread::is_exiting()` will return true before the target >> JavaThread is removed from the system's current ThreadsList. So the >> `JavaThread::is_exiting()` check will return true faster and the >> `ThreadsListHandle::includes()` check. >> >> However, that change in behavior does not result in a change in >> behavior for a suspend thread request. Here's the relevant code: >> >> >> src/hotspot/share/runtime/thread.cpp: >> void JavaThread::exit(bool destroy_vm, ExitType exit_type) { >> >> >> // The careful dance between thread suspension and exit is handled here. >> // Since we are in thread_in_vm state and suspension is done with handshakes, >> // we can just put in the exiting state and it will be correctly handled. >> set_terminated(_thread_exiting); >> >> >> >> // Remove from list of active threads list, and notify VM thread if we are the last non-daemon thread >> Threads::remove(this, daemon); >> >> >> } >> >> >> When we changed the suspend thread mechanism to use handshakes, we >> made it so that once the JavaThread called `set_terminated(_thread_exiting)` >> it no longer had to honor a suspend thread request. >> >> Summary: Yes, the `is_exiting()` call will result in detecting the exiting >> JavaThread sooner than the `ThreadsListHandle::includes()` check. >> However, it will not result in a change in suspend thread behavior. > > The `is_exiting` check seems unnecessary as the handshake code will not handshake with an exiting thread. The nested TLH was unnecessary too AFAICS. Ummmm... The purpose of the new `is_exiting()` check and the baseline's `ThreadsListHandle::includes()` check is to avoid making this call: return this->handshake_state()->suspend(); The call we are avoiding is the one that makes the synchronous SuspendThreadHandshake request (for threads other than self) so by detecting the exiting thread early, we are avoiding entering the handshake machinery. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Sat Oct 30 20:41:21 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Sat, 30 Oct 2021 20:41:21 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Restore update of copyright messages in resource files Thanks again, Chris and Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From cjplummer at openjdk.java.net Sun Oct 31 17:34:17 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sun, 31 Oct 2021 17:34:17 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: On Sat, 30 Oct 2021 20:00:26 GMT, Jakob Cornell wrote: >> Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore update of copyright messages in resource files > > Thanks again, Chris and Ioi! @jakobcornell It looks like we have a couple of intermittent test failures that need investigating. Can you please have a look at [JDK-8276208](https://bugs.openjdk.java.net/browse/JDK-8276208)? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Sun Oct 31 20:18:17 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Sun, 31 Oct 2021 20:18:17 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Restore update of copyright messages in resource files Just verified that this test still passes for me locally on LInux. I see from Daniel's test logs where the behavior is differing on the Windows build, and I'll see if I can reproduce it on a Windows system. I'll also look into fixing the issue of the `AssertionError`s being ignored. But I wonder if it would be better to throw `RuntimeException` instead of calling `failure`. If an assertion fails, the state of the debugger may be incompatible with the state of the test code, and it seem most natural to me that it be aborted at that point. Should I open a new pull request linked to 8276208 for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From ddong at openjdk.java.net Sun Oct 31 22:56:44 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 31 Oct 2021 22:56:44 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of this fix that corrects the oop size value of dtrace_object_alloc(_base). > > JDK-8039904 added a new parameter 'size' to SharedRuntime::dtrace_object_alloc and dtrace_object_alloc_base, but didn't modified the callsites(interpreter/c1/c2). > > To make this fix as simple as possible, I overloaded dtrace_object_alloc_base rather than dtrace_object_alloc. > > Thanks, > Denghui Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: fix build problem ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6181/files - new: https://git.openjdk.java.net/jdk/pull/6181/files/a5ecbff4..8d597ebc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6181&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6181&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6181/head:pull/6181 PR: https://git.openjdk.java.net/jdk/pull/6181 From cjplummer at openjdk.java.net Sun Oct 31 23:04:16 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sun, 31 Oct 2021 23:04:16 GMT Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: On Mon, 25 Oct 2021 22:21:54 GMT, Jakob Cornell wrote: >> This has been under discussion on and off for the past month or so on serviceability-dev, and I think a CSR request is required, so this may be a work in progress. >> >> Notes on the patch: >> >> - The `list` command previously marked a line in each listing with `=>`. In a bare `list` this is the next line up for execution. Previously when requesting a specific location (e.g. `list 5`) the requested line would be marked. With the patch applied, `list` will only ever mark the next line up for execution. This is consistent with the behavior of GDB and PDB (at least). >> - `EOF` is printed when the repeat setting is on and a bare `list` command follows a listing containing the last source line. This feature is from PDB; it's a somewhat softer message than the one for an explicit `list` request that's out of range. >> - I don't speak Chinese or Japanese, so I've omitted localizations for the new messages in those locales. However, I updated the help text in both to include the new commands, with the descriptions left empty for now. > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Restore update of copyright messages in resource files I would suggest either `Failure` or `TestFailure` instead of `RuntimeException` (and they both inherit from `RuntimeException`). This is what other tests do instead of throwing `RuntimeException`. From an implementation standpoint the two are identical. However, what I've noticed is that a lot of tests catch `Failure`, but not `TestFailure`, and it almost always looks something like: } catch (Failure e) { log.complain("TEST FAILED: " + e.getMessage()); success = false; ... if (!success) { log.complain("TEST FAILED"); return FAILED; } But those are all in jdi and jdwp tests. Jdb tests seem to almost alway use the `failure()` method, which is the same as the first part of the above code, and then later `JdbTest.runtTest()` does the 2nd part, so I think using `failure()` is more consistent. Yes, this does mean the test will continue to run. This seems to be the way most of these tests work. A failure does not indicate that the test should be aborted, and it will continue doing more test cases. Sometimes this is appropriate. I'm sure plenty of times it's not, but I think erring on the side of continuing to run the test is generally more useful. The PR for 8276208 should contain the fix for the failures. If you want to also clean up the AssertionError issue at the same time, that's ok, or I can file a separate CR for that part if you wish. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290