From dholmes at openjdk.java.net Mon Nov 1 01:59:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 1 Nov 2021 01:59: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> <_BHkTmhKZL2DIpDaQtXiYt3G7pgICjdPZBsvSKZtMGY=.e42c5f19-c520-4561-add3-87599ce83e6b@github.com> <_wTFvKifcBa8ays6OPjvBWPNUeMhaJHx38C2n1GGwmc=.e79a3d43-c5ef-4fe3-8a9a-60f5f1f2cbe8@github.com> Message-ID: On Fri, 29 Oct 2021 22:35:50 GMT, Daniel D. Daugherty wrote: >> 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. But why do we care about that? The low-level mechanism handles exiting threads so there is no need for the higher-level code to do that. The current logic gives the appearance that we must filter out exiting threads at this level because the lower-level code does not handle them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Mon Nov 1 03:19:17 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 03:19: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 Okay, I'll change those tests to use `failure`, and I'm okay doing that in the same PR. Unfortunately I'm no longer able to build the JDK at `master`; I seem to be getting the same error that [this person did](https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031907.html) in August. Since the test classes depend on the JDK itself I'm not able to verify that the changes to the tests are correct (e.g. compile). I suppose if others aren't seeing the same build error I could create that PR anyway and let someone else test the change. Also, Daniel's failing Windows build seems to be caused by the command `2 2 up` only executing `up` once rather than 4 times, and I wasn't able to reproduce that JDB behavior on `master` on the Windows system I have access to. On both of these items, I'm not sure how to proceed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From david.holmes at oracle.com Mon Nov 1 03:33:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Nov 2021 13:33:18 +1000 Subject: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v8] In-Reply-To: References: Message-ID: <37ebabc4-8d33-987a-38e5-f0c99358c18e@oracle.com> On 1/11/2021 1:19 pm, Jakob Cornell wrote: > 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 > > Okay, I'll change those tests to use `failure`, and I'm okay doing that in the same PR. Unfortunately I'm no longer able to build the JDK at `master`; I seem to be getting the same error that [this person did](https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031907.html) in August. Since the test classes depend on the JDK itself I'm not able to verify that the changes to the tests are correct (e.g. compile). I suppose if others aren't seeing the same build error I could create that PR anyway and let someone else test the change. That issue was a problem with the boot JDK being too old. make sure you are using the GA version of JDK 17. Cheers, David ----- > Also, Daniel's failing Windows build seems to be caused by the command `2 2 up` only executing `up` once rather than 4 times, and I wasn't able to reproduce that JDB behavior on `master` on the Windows system I have access to. > > On both of these items, I'm not sure how to proceed. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5290 > From duke at openjdk.java.net Mon Nov 1 04:52:19 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 04:52:19 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 The JDK build issue is resolved (thanks David Holmes). The switch to `failure` is now implemented in #6182, and I think we can move the discussion there. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From dcubed at openjdk.java.net Mon Nov 1 15:40:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Nov 2021 15:40:37 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Message-ID: macOS12 has changed the dladdr() function to accept "-1" as a valid address and we have functions that use dladdr() to convert DLL addresses into function or library names. We also have a gtest that verifies that "-1" is not a valid value to use as a symbol address. As you might imagine, existing code that uses `os::dll_address_to_function_name()` or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) if an `addr` parameter of `-1` was allowed to be used. I've also made two cleanup changes as part of this fix: 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should be properly `#ifdef`'ed. There is also some code that makes sense for ELF format files, but not for Mach-O format files so that code needs to be excluded on macOS. 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code base so I'd like to fix it with this bug ID since I'm in related areas. This fix has been tested with Mach5 Tier[1-6]. ------------- Commit messages: - 8273967.cr0.patch Changes: https://git.openjdk.java.net/jdk/pull/6193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6193&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273967 Stats: 50 lines in 4 files changed: 43 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6193/head:pull/6193 PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Mon Nov 1 15:58:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Nov 2021 15:58:47 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v9] 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 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 10 additional commits since the last revision: - Merge branch 'master' into JDK-8249004 - coleenp CR - add comments to clarify what WB_HandshakeReadMonitors() and WB_HandshakeWalkStack() expect. - dholmes CR - change NULL to nullptr. - 8249004.cr1.patch - 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/9518a9a8..045b3e0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=07-08 Stats: 44007 lines in 1055 files changed: 33358 ins; 6622 del; 4027 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 Nov 1 16:10:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Nov 2021 16:10:11 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 Sat, 16 Oct 2021 15:58:21 GMT, Daniel D. Daugherty wrote: >> 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. Update again: I took a closer look at `WB_AsyncHandshakeWalkStack()`, `WB_HandshakeReadMonitors()` and `WB_HandshakeWalkStack()` and I realized that those functions were not properly converting a `jobject` into a protected JavaThread*. I've updated them to call the proper conversion function and I've changed this code to `guarantee()` that the target is not `nullptr`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Mon Nov 1 16:10:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Nov 2021 16:10:13 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: <_POkzAx-bkPHRD8xDAT0S0qxMhZ84JVioGP5JVmQ4XY=.489c7ba1-71e8-4472-b56a-26fdbf609a1b@github.com> On Fri, 29 Oct 2021 22:16:17 GMT, Daniel D. Daugherty wrote: >> 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. Testing went well so the above change will be in the next change that I push. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Mon Nov 1 16:10:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 1 Nov 2021 16:10: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: <9tsrUbjC-CRvC0xqLq_EWx8fBH5GXxLnSpPsadT2a4s=.5004e1bc-492f-4770-bfa7-e150ef5f30da@github.com> On Mon, 1 Nov 2021 01:55:48 GMT, David Holmes wrote: >> 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. > > But why do we care about that? The low-level mechanism handles exiting threads so there is no need for the higher-level code to do that. The current logic gives the appearance that we must filter out exiting threads at this level because the lower-level code does not handle them. Okay you've convinced me. I'm merging my latest patch with master and then I'll retest with the is_exiting() check removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From cjplummer at openjdk.java.net Mon Nov 1 16:23:19 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 1 Nov 2021 16:23:19 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, 1 Nov 2021 04:49:31 GMT, Jakob Cornell wrote: > The JDK build issue is resolved (thanks David Holmes). The switch to `failure` is now implemented in #6182, and I think we can move the discussion there. #6182 is still a draft. Was that intentional? No emails will go out while it is a draft. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Mon Nov 1 16:31:20 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 16:31:20 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 Yes, I made it a draft because it's not ready for review yet. I'll undo that though to allow the email system to work. Thanks for the heads up. ------------- PR: https://git.openjdk.java.net/jdk/pull/5290 From duke at openjdk.java.net Mon Nov 1 16:32:26 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 16:32:26 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Message-ID: This will fix a few issues with the tests added in #5290: - [ ] intermittent failures - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` ------------- Commit messages: - Use `failure' method instead of `AssertionError' in new tests Changes: https://git.openjdk.java.net/jdk/pull/6182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6182&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276208 Stats: 23 lines in 2 files changed: 1 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/6182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6182/head:pull/6182 PR: https://git.openjdk.java.net/jdk/pull/6182 From duke at openjdk.java.net Mon Nov 1 16:32:27 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 16:32:27 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [ ] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` I'm not sure whether this is expected to be a platform-specific bug, but I've been assuming it is since I've never seen the failure on my Linux system. I started with the Windows failure and noticed that the JDB loop mechanism doesn't seem to be working: Sending command: 2 2 up reply[0]: End of stack. reply[1]: main[1] That would seem to be the cause of the "Unexpected output" error, but I can't reproduce the behavior manually on the x86-64 Windows system I have access to. With repeat on: main[1] 2 2 up End of stack. main[1] End of stack. main[1] End of stack. main[1] End of stack. main[1] I wonder if Daniel can provide any more information that might enable me to reproduce the issue for debugging. If not, I don't think I can diagnose the issue. Another question I have is whether anybody has attempted to find the point the bug was introduced by backporting the test to earlier versions of the JDK. I think that would essentially mean reducing the test to `2 2 up` or similar, since the `repeat` command is brand new. I'm assuming the Mach 5 failure has the same underlying cause; I could try virtualizing Linux on PowerPC to try to reproduce that one, but that seems likely to take a lot of time and unlikely to turn up anything useful. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From duke at openjdk.java.net Mon Nov 1 16:37:07 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Mon, 1 Nov 2021 16:37:07 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: <9EFMj5cjeiQwuwsdSWBeUMOxtjcFDY96I8-i6_OKqJk=.3a9aa70b-22b8-4334-bdf9-b5257989e1af@github.com> On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [ ] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` This isn't ready for review; I'm just marking it such to enable integration with the mailing list. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From cjplummer at openjdk.java.net Mon Nov 1 18:50:10 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 1 Nov 2021 18:50:10 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: <075r1PQ-WBmhFr7NI1iXSpVzBDSxVyOR2qod2WYJM2Q=.0ea32b9a-2a3d-4013-ac2e-db00f0ebe9c9@github.com> On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [ ] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` Dan did reproduce the "Unexpected Output" failure on linux. I'm trying to reproduce now, including linux, windows, and macosx. I want to first get a better idea of how frequently it reproduces. Keep in mind that there were extra VM flags applied on all the runs that failed. Try running with the following: `-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:-DoEscapeAnalysis` Most of these are probably unnecessary or aren't even impacting how VM is run (ie -Xcomp probably makes -XX:CompileThreshold=100 not do anything). If anything, -Xcomp might be making a difference. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From cjplummer at openjdk.java.net Mon Nov 1 19:14:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 1 Nov 2021 19:14:09 GMT Subject: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string In-Reply-To: References: Message-ID: <9COBgkGYs_smiEoX76yeoTijGMO6p1_9AADzCJ1q2kQ=.fbabb777-bb9f-4c26-9c7b-be56593b1d07@github.com> 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) Ok. You can proceed with your current fix if you'd like. ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From lmesnik at openjdk.java.net Mon Nov 1 19:27:14 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 1 Nov 2021 19:27: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) Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From chris.plummer at oracle.com Mon Nov 1 19:35:08 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Nov 2021 12:35:08 -0700 Subject: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd In-Reply-To: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> Message-ID: <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> An HTML attachment was scrubbed... URL: From cjplummer at openjdk.java.net Mon Nov 1 20:20:11 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 1 Nov 2021 20:20:11 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [ ] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` I did 20 runs each on linux, mac, and windows. I got 4 "Unexpected output" failures, 3 on mac and 1 on windows. I applied the fix to use `failure()`, and it seems this failure is also due to the `2 2 up` command not working right: Sending command: repeat on reply[0]: main[1] Sending command: repeat reply[0]: Repeat is on reply[1]: main[1] Sending command: print 0 reply[0]: 0 = 0 reply[1]: main[1] Sending command: reply[0]: main[1] Sending command: 2 2 up reply[0]: End of stack. reply[1]: main[1] # ERROR: Unexpected output The following stacktrace is for failure analysis. nsk.share.TestFailure: Unexpected output at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432) at nsk.share.Log.complain(Log.java:403) at nsk.share.jdb.JdbTest.failure(JdbTest.java:74) at nsk.jdb.repeat.repeat001.repeat001.runCasesNoCleanup(repeat001.java:142) at nsk.jdb.repeat.repeat001.repeat001.runCases(repeat001.java:87) at nsk.share.jdb.JdbTest.runTest(JdbTest.java:149) at nsk.jdb.repeat.repeat001.repeat001.run(repeat001.java:77) at nsk.jdb.repeat.repeat001.repeat001.main(repeat001.java:71) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) Sending command: reply[0]: End of stack. reply[1]: main[1] End of stack. reply[2]: main[1] End of stack. reply[3]: main[1] End of stack. reply[4]: main[1] # ERROR: Repeated command didn't repeat correctly ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From cjplummer at openjdk.java.net Mon Nov 1 20:31:15 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 1 Nov 2021 20:31:15 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: <49Rtxh9HqO_KeyCUNpOkjUXclviB5peQWdbKYoQ7Nwk=.6e61b2aa-fdd6-47bc-b7c5-b8e541be480c@github.com> On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [ ] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` I'm pretty sure the problem is with how you are calling `jdb.receiveReplyFor("2 2 " + JdbCommand.up)`. `receiveReplyFor()` is only going to wait for 1 prompt to be returned. I think usually they are all returned together, so usually you get all 4 prompts, but sometimes they get split up. The way to fix this is to use `jdb.receiveReplyFor("2 2 " + JdbCommand.up, true, 4)` since you want to wait for 4 prompts. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From duke at openjdk.java.net Mon Nov 1 21:00:29 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Mon, 1 Nov 2021 21:00:29 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics Message-ID: This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. Testing: - `make test TEST="gtest"`: Passed - `make run-test TEST="tier1"`: Passed - `make run-test TEST="tier2"`: Passed - `make run-test TEST=`: serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java ------------- Commit messages: - 8275729: Qualified method names in CodeHeap Analytics Changes: https://git.openjdk.java.net/jdk/pull/6200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275729 Stats: 75 lines in 2 files changed: 75 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6200/head:pull/6200 PR: https://git.openjdk.java.net/jdk/pull/6200 From david.holmes at oracle.com Mon Nov 1 21:55:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Nov 2021 07:55:37 +1000 Subject: RFR: 8275775: VM.metaspace prints flag 'f' for classes that have non-trivial finalize() [v3] In-Reply-To: References: Message-ID: On 1/11/2021 5:19 pm, Yi Yang wrote: > On Wed, 27 Oct 2021 01:30:37 GMT, Yi Yang wrote: > >>> Some customers want to observe which loaded classes have overridden the finalize() method. I found that VM.metaspace can output detailed classes. It seems feasible to add 'f' flag to it. With this patch, I found that ZipFileSystem left a finalize after applying this patch, which was obsolete 5 years ago, maybe we should remove it? >> >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> typo > > Hi David, > >> Do we have sufficient class information to combine with the finalize() status, remembering that we will be reporting on every single class, to make VM.classes worthwhile? Would a simple command to list all non-trivially-finalizable classes be useful in itself? VM.finalizable_classes? > > VM.finalizable_classes seems to be too ad-hoc. The only purpose is to print the class that has non-trivial finalize() method. If, maybe one day in the future, we want to know which classes have miranda method, we may need to add another VM.miranda_classes command. VM.classes can print detailed information of all loaded classes of the JVM, which looks more extensible and flexible. My concern is there will be too much information to be useful if you simply list and flag every single loaded class. We are basically trying to make a decision whether to add a command that asks a specific query (show me all finalizable classes), versus a command that just produces a class dump and the user then has to manually apply their query to that raw data. There are pros and cons to each approach. This also seems more of a serviceability issue so I've cc'd that mailing list. Also this now relates to the new JEP on finalization removal: https://openjdk.java.net/jeps/421 as a tool to help users see where finalizers exist will be useful to that effort. Cheers, David > Thanks. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/6075 > From david.holmes at oracle.com Mon Nov 1 23:00:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Nov 2021 09:00:02 +1000 Subject: RFR: 8275775: VM.metaspace prints flag 'f' for classes that have non-trivial finalize() [v3] In-Reply-To: References: Message-ID: <98cc726d-6fab-4fc0-fe89-e12cb13af600@oracle.com> On 2/11/2021 7:55 am, David Holmes wrote: > On 1/11/2021 5:19 pm, Yi Yang wrote: >> On Wed, 27 Oct 2021 01:30:37 GMT, Yi Yang wrote: >> >>>> Some customers want to observe which loaded classes have overridden >>>> the finalize() method. I found that VM.metaspace can output detailed >>>> classes. It seems feasible to add 'f' flag to it. With this patch, I >>>> found that ZipFileSystem left a finalize after applying this patch, >>>> which was obsolete 5 years ago, maybe we should remove it? >>> >>> Yi Yang has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? typo >> >> Hi David, >> >>> Do we have sufficient class information to combine with the >>> finalize() status, remembering that we will be reporting on every >>> single class, to make VM.classes worthwhile? Would a simple command >>> to list all non-trivially-finalizable classes be useful in itself? >>> VM.finalizable_classes? >> >> VM.finalizable_classes seems to be too ad-hoc. The only purpose is to >> print the class that has non-trivial finalize() method. If, maybe one >> day in the future, we want to know which classes have miranda method, >> we may need to add another VM.miranda_classes command. VM.classes can >> print detailed information of all loaded classes of the JVM, which >> looks more extensible and flexible. > > My concern is there will be too much information to be useful if you > simply list and flag every single loaded class. We are basically trying > to make a decision whether to add a command that asks a specific query > (show me all finalizable classes), versus a command that just produces a > class dump and the user then has to manually apply their query to that > raw data. There are pros and cons to each approach. It has been pointed out (thanks Alex) that we already have VM.class_hierarchy to print all classes, so perhaps that could be augmented to add a decorator for finalizable classes? David > This also seems more of a serviceability issue so I've cc'd that mailing > list. > > Also this now relates to the new JEP on finalization removal: > > https://openjdk.java.net/jeps/421 > > as a tool to help users see where finalizers exist will be useful to > that effort. > > Cheers, > David > >> Thanks. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/6075 >> From duke at openjdk.java.net Tue Nov 2 01:07:30 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Tue, 2 Nov 2021 01:07:30 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [x] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` That certainly does make sense, although it makes me wonder how this ever passed in the first place. Maybe there's a bug somewhere in the JDB output processing code that made the failure intermittent. In any case, it should be resolved now. Thanks for doing the heavy lifting on investigation and debugging here. I did have another question related to these tests. I used a record class in the implementation of the `list003` test and I since learned that that's a preview feature. Should I rework the test to avoid using record classes in case the feature is dropped later? ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From duke at openjdk.java.net Tue Nov 2 01:07:30 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Tue, 2 Nov 2021 01:07:30 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2] In-Reply-To: References: Message-ID: > This will fix a few issues with the tests added in #5290: > > - [x] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect use of `receiveReplyFor' causing test failures ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6182/files - new: https://git.openjdk.java.net/jdk/pull/6182/files/817884d9..8359ab8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6182&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6182&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6182/head:pull/6182 PR: https://git.openjdk.java.net/jdk/pull/6182 From david.holmes at oracle.com Tue Nov 2 01:11:45 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Nov 2021 11:11:45 +1000 Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: <90da39dd-4e12-245f-a3a3-ffa1cfd7e9cb@oracle.com> On 2/11/2021 11:07 am, Jakob Cornell wrote: > On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` > > That certainly does make sense, although it makes me wonder how this ever passed in the first place. Maybe there's a bug somewhere in the JDB output processing code that made the failure intermittent. In any case, it should be resolved now. Thanks for doing the heavy lifting on investigation and debugging here. > > I did have another question related to these tests. I used a record class in the implementation of the `list003` test and I since learned that that's a preview feature. Should I rework the test to avoid using record classes in case the feature is dropped later? Records were a preview feature in JDK 14 and 15, but are a full feature since JDK 16. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/6182 > From duke at openjdk.java.net Tue Nov 2 01:25:10 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Tue, 2 Nov 2021 01:25:10 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 01:07:30 GMT, Jakob Cornell wrote: >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect use of `receiveReplyFor' causing test failures Oh good. I haven't been following recent releases very closely. So this is ready for review then. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From cjplummer at openjdk.java.net Tue Nov 2 01:44:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 2 Nov 2021 01:44:13 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 01:07:30 GMT, Jakob Cornell wrote: >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect use of `receiveReplyFor' causing test failures Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From cjplummer at openjdk.java.net Tue Nov 2 01:44:13 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 2 Nov 2021 01:44:13 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: <90da39dd-4e12-245f-a3a3-ffa1cfd7e9cb@oracle.com> References: <90da39dd-4e12-245f-a3a3-ffa1cfd7e9cb@oracle.com> Message-ID: <0BCUnEWoFe6yuhOuHDIMKsYQeOEqZRc_pDwB0LtcgHE=.a77f8453-e1c2-4ac7-b749-2f4a44e6df4f@github.com> On Tue, 2 Nov 2021 01:13:40 GMT, David Holmes wrote: > That certainly does make sense, although it makes me wonder how this ever passed in the first place. Maybe there's a bug somewhere in the JDB output processing code that made the failure intermittent. It depends a bit on how the underlying I/O bundles up the reply packets, and how quickly they are read, but probably more the latter than the former. Basically the jdb process is sending a bunch of replies, and the test process usually doesn't start reading the replies until after they have all been sent, so it gets them all with one read. But if the test process is quick enough, then it might do the read before all the replies have been sent. ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From denghui.ddh at alibaba-inc.com Tue Nov 2 03:09:56 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 02 Nov 2021 11:09:56 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogRXh0ZW5kIERDbWQoRGlhZ25vc3RpYy1Db21tYW5kKSBmcmFtZXdvcmsgdG8g?= =?UTF-8?B?c3VwcG9ydCBKYXZhIGxldmVsIERDbWQ=?= In-Reply-To: <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com>, <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> Message-ID: <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> Hi Chris, Thank you for the comments. Yes, we have no good way to restrict the user registration commands to only include diagnosis-related operations, but in my opinion, this does not seem to be a problem that must be solved perfectly. The following are my thoughts. This extension is an entry that triggers the operation that the user wants to perform (similar to the Signal Handler mechanism but with a name and parameters). Even without this extension, the user can have other ways to achieve the same goal. On the one hand, we could standardize the usage scenarios of the API on the document(Indeed, users can still write programs not in accordance with the specifications, for example, users can implement multiple calls to the same object's hachCode method to return different values or make an object alive again during finalize method executing). On the other hand, we can add some restrictions to help users make better use of this extension. e.g we can add a new VM option, such as EnableUserLevelDCmd, the application can only register customer commands when this option is enabled. Or from another perspective, can we allow users to do some non-diagnostic-related operations in custom commands? Best, Denghui ------------------------------------------------------------------ From:Chris Plummer Send Time:2021?11?2?(???) 03:35 To:???(??) ; serviceability-dev ; hotspot-dev Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd I have similar concerns to those others have expressed, so I'll try to add something new to the discussion and not just repeat. DCMDs have historically been very VM centric. That's not to say they aren't useful for debugging applications, but they do so by providing VM related info like stack traces, heap dumps, and class histograms. Also hotspot has been the gatekeeper for new DCMDs, meaning that new ones do not get added without going through the hotspot review process. Allowing any application or framework to add a DCMD changes this VM centric view in a way that concerns me. This approach allows a DCMD to pretty much do anything (java security not withstanding). App writers could even use them to provide a user facing interface. For example, if an app has some sort internal database, it could allow users to query it via a DCMD, and maybe even suggest that users write simple shell scripts that use jcmd to do these queries. Allowing this type of non-diagnostic usage seems like a path we don't want to go down, yet I don't see how it can be prevented once you allow applications to add DCMDs. Chris On 10/25/21 1:37 AM, Denghui Dong wrote: 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 denghui.ddh at alibaba-inc.com Tue Nov 2 03:20:47 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 02 Nov 2021 11:20:47 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogRXh0ZW5kIERDbWQoRGlhZ25vc3RpYy1Db21tYW5kKSBmcmFtZXdvcmsgdG8g?= =?UTF-8?B?c3VwcG9ydCBKYXZhIGxldmVsIERDbWQ=?= In-Reply-To: <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com>, <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com>, <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> Message-ID: <967efbed-b345-462a-943c-c171b410cc21.denghui.ddh@alibaba-inc.com> By the way, Erik mentioned that the DCmd command in JFR is unlikely to use this extension. But there are some other VM commands I think can be easily replaced with this extension, such as RunFinalizationDCmd, FinalizerInfoDCmd, PrintSystemPropertiesDCmd, JMX-related DCmds, etc. Denghui ------------------------------------------------------------------ From:???(??) Send Time:2021?11?2?(???) 11:09 To:serviceability-dev ; hotspot-dev ; Chris Plummer Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd Hi Chris, Thank you for the comments. Yes, we have no good way to restrict the user registration commands to only include diagnosis-related operations, but in my opinion, this does not seem to be a problem that must be solved perfectly. The following are my thoughts. This extension is an entry that triggers the operation that the user wants to perform (similar to the Signal Handler mechanism but with a name and parameters). Even without this extension, the user can have other ways to achieve the same goal. On the one hand, we could standardize the usage scenarios of the API on the document(Indeed, users can still write programs not in accordance with the specifications, for example, users can implement multiple calls to the same object's hachCode method to return different values or make an object alive again during finalize method executing). On the other hand, we can add some restrictions to help users make better use of this extension. e.g we can add a new VM option, such as EnableUserLevelDCmd, the application can only register customer commands when this option is enabled. Or from another perspective, can we allow users to do some non-diagnostic-related operations in custom commands? Best, Denghui ------------------------------------------------------------------ From:Chris Plummer Send Time:2021?11?2?(???) 03:35 To:???(??) ; serviceability-dev ; hotspot-dev Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd I have similar concerns to those others have expressed, so I'll try to add something new to the discussion and not just repeat. DCMDs have historically been very VM centric. That's not to say they aren't useful for debugging applications, but they do so by providing VM related info like stack traces, heap dumps, and class histograms. Also hotspot has been the gatekeeper for new DCMDs, meaning that new ones do not get added without going through the hotspot review process. Allowing any application or framework to add a DCMD changes this VM centric view in a way that concerns me. This approach allows a DCMD to pretty much do anything (java security not withstanding). App writers could even use them to provide a user facing interface. For example, if an app has some sort internal database, it could allow users to query it via a DCMD, and maybe even suggest that users write simple shell scripts that use jcmd to do these queries. Allowing this type of non-diagnostic usage seems like a path we don't want to go down, yet I don't see how it can be prevented once you allow applications to add DCMDs. Chris On 10/25/21 1:37 AM, Denghui Dong wrote: 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 yyang at openjdk.java.net Tue Nov 2 05:52:15 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 2 Nov 2021 05:52:15 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed This looks good now. Old output can not tell us which class the method belongs to. compiler method Addr(module) offset size type lvl temp blobType Name 0x00007f08adc94010 (+0x00000010) 0x00000150( 0K) c1 3 480 nMethod (deopt) nmethod 0x00007f08adc94390 (+0x00000390) 0x000001b0( 0K) c1 3 480 nMethod (active) java.lang.String.isLatin1()Z 0x00007f08adc94710 (+0x00000710) 0x00000258( 0K) c1 3 480 nMethod (active) jdk.internal.util.Preconditions.checkIndex(IILjava/util/function/BiFunction;)I 0x00007f08adc94b90 (+0x00000b90) 0x000004e8( 1K) c1 3 480 nMethod (deopt) nmethod 0x00007f08adc95310 (+0x00001310) 0x00000298( 0K) c1 3 480 nMethod (active) java.lang.StringLatin1.charAt([BI)C 0x00007f08adc95790 (+0x00001790) 0x000001a0( 0K) c1 3 480 nMethod (active) java.lang.String.checkIndex(II)V 0x00007f08adc95b10 (+0x00001b10) 0x00000170( 0K) c1 3 480 nMethod (active) java.lang.String.coder()B 0x00007f08adc95e90 (+0x00001e90) 0x000003e8( 0K) c1 3 480 nMethod (active) java.lang.String.hashCode()I 0x00007f08adc96490 (+0x00002490) 0x00000130( 0K) c1 3 480 nMethod (deopt) nmethod 0x00007f08adc96790 (+0x00002790) 0x00000210( 0K) c1 3 480 nMethod (active) java.lang.String.length()I ------------- Marked as reviewed by yyang (Committer). PR: https://git.openjdk.java.net/jdk/pull/6200 From sgehwolf at openjdk.java.net Tue Nov 2 10:42:12 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 2 Nov 2021 10:42:12 GMT Subject: Integrated: 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) This pull request has now been integrated. Changeset: 9971a2ca Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 Stats: 104 lines in 6 files changed: 0 ins; 100 del; 4 mod 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/6156 From thartmann at openjdk.java.net Tue Nov 2 11:01:12 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 2 Nov 2021 11:01:12 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6200 From simonis at openjdk.java.net Tue Nov 2 16:38:20 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 2 Nov 2021 16:38:20 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed src/hotspot/share/code/codeHeapState.cpp line 2340: > 2338: > 2339: Klass* klass = method->method_holder(); > 2340: assert(klass->is_loader_alive(), "must be alive"); Are you sure `klass` is always valid here and that its class loader has to be alive (i.e. the corresponding class hasn't been unloaded in the meantime)? In [https://bugs.openjdk.java.net/browse/JDK-8275729](JDK-8275729) you say that the Top50 list already has qualified names but as far as I know, that information is already collected in the aggregation step where it is safe. You now query this information in the reporting step. I know we had problems due to access to dead methods before (see [JDK-8219586: CodeHeap State Analytics processes dead nmethods](https://bugs.openjdk.java.net/browse/JDK-8219586) and I just want to make sure we don't re-introduce such problems. Maybe @RealLucy or @fisk can have an additional look? ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From duke at openjdk.java.net Tue Nov 2 16:38:22 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 2 Nov 2021 16:38:22 GMT Subject: Integrated: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed This pull request has now been integrated. Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 Stats: 75 lines in 2 files changed: 75 ins; 0 del; 0 mod 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From phh at openjdk.java.net Tue Nov 2 16:42:21 2021 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 2 Nov 2021 16:42:21 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed Volker, I sponsored this before you posted your review. Evgeny, if it's a problem, please file a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From simonis at openjdk.java.net Tue Nov 2 16:42:21 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 2 Nov 2021 16:42:21 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed No problem, I know I was late :) But I also know that this is a sensitive area, so better double check... ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From dcubed at openjdk.java.net Tue Nov 2 16:54:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 16:54:33 GMT Subject: Integrated: 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Message-ID: A trivial fix to ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java ------------- Commit messages: - 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Changes: https://git.openjdk.java.net/jdk/pull/6214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276367 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6214/head:pull/6214 PR: https://git.openjdk.java.net/jdk/pull/6214 From bpb at openjdk.java.net Tue Nov 2 16:54:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Nov 2021 16:54:34 GMT Subject: Integrated: 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:34:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6214 From dcubed at openjdk.java.net Tue Nov 2 16:54:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 16:54:34 GMT Subject: Integrated: 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:47:08 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6214 From dcubed at openjdk.java.net Tue Nov 2 16:54:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 16:54:34 GMT Subject: Integrated: 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:34:26 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java This pull request has now been integrated. Changeset: 01105d69 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/01105d6985b39d4064b9066eab3612da5a401685 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/6214 From duke at openjdk.java.net Tue Nov 2 17:08:17 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 2 Nov 2021 17:08:17 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 16:34:34 GMT, Volker Simonis wrote: >> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. >> Testing: >> - `make test TEST="gtest"`: Passed >> - `make run-test TEST="tier1"`: Passed >> - `make run-test TEST="tier2"`: Passed >> - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed > > src/hotspot/share/code/codeHeapState.cpp line 2340: > >> 2338: >> 2339: Klass* klass = method->method_holder(); >> 2340: assert(klass->is_loader_alive(), "must be alive"); > > Are you sure `klass` is always valid here and that its class loader has to be alive (i.e. the corresponding class hasn't been unloaded in the meantime)? > > In [https://bugs.openjdk.java.net/browse/JDK-8275729](JDK-8275729) you say that the Top50 list already has qualified names but as far as I know, that information is already collected in the aggregation step where it is safe. You now query this information in the reporting step. > > I know we had problems due to access to dead methods before (see [JDK-8219586: CodeHeap State Analytics processes dead nmethods](https://bugs.openjdk.java.net/browse/JDK-8219586) and I just want to make sure we don't re-introduce such problems. > > Maybe @RealLucy or @fisk can have an additional look? @simonis The code is guarded by checks: // access nmethod and Method fields only if we own the CodeCache_lock. // This fact is implicitly transported via nm != NULL. if (nmethod_access_is_safe(nm)) { ... bool get_name = (cbType == nMethod_inuse) || (cbType == nMethod_notused); ... if (get_name) { I was thinking whether I should use `if (klass->is_loader_alive())` or `assert(klass->is_loader_alive())`. I chose the assert because if it is safe to access `Method` than its holder `Klass` must be alive. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From dcubed at openjdk.java.net Tue Nov 2 17:26:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 17:26:41 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] 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: 8249004.cr2.patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/045b3e0d..3e1d1b06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=08-09 Stats: 128 lines in 5 files changed: 22 ins; 46 del; 60 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 Tue Nov 2 17:26:44 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 17:26:44 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:31:26 GMT, Coleen Phillimore wrote: >> 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. @coleenp and @dholmes-ora, the latest version should address the last of your previous comments. Please re-review when you get the chance. @robehn and @sspitsyn - It would be good to get re-reviews from you guys on this latest version. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Tue Nov 2 18:14:23 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 2 Nov 2021 18:14:23 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 05:49:30 GMT, Yi Yang wrote: >> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. >> Testing: >> - `make test TEST="gtest"`: Passed >> - `make run-test TEST="tier1"`: Passed >> - `make run-test TEST="tier2"`: Passed >> - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed > > This looks good now. Old output can not tell us which class the method belongs to. > > > Old: > 0x00007f6e91063010 (+0x00000010) 0x000000a0( 0K) none 0 480 nMethod (deopt) nmethod > 0x00007f6e91063310 (+0x00000310) 0x000000f8( 0K) none 0 480 nMethod (active) name()Ljava/lang/String; > 0x00007f6e91063610 (+0x00000610) 0x000000f8( 0K) none 0 480 nMethod (active) descriptor()Ljava/lang/module/ModuleDescriptor; > 0x00007f6e91063910 (+0x00000910) 0x00000000( 0K) none 0 480 nMethod (active) getReferenceVolatile(Ljava/lang/Object;J)Ljava/lang/Object; > 0x00007f6e91063d90 (+0x00000d90) 0x00000000( 0K) none 0 480 nMethod (active) hashCode()I > 0x00007f6e91064190 (+0x00001190) 0x000000f8( 0K) c1 1 480 nMethod (active) name()Ljava/lang/String; > 0x00007f6e91064490 (+0x00001490) 0x000000f8( 0K) c1 1 480 nMethod (active) modifiers()Ljava/util/Set; > 0x00007f6e91064790 (+0x00001790) 0x000000f8( 0K) c1 1 480 nMethod (active) targets()Ljava/util/Set; > 0x00007f6e91064a90 (+0x00001a90) 0x000000f8( 0K) c1 1 480 nMethod (active) source()Ljava/lang/String; > 0x00007f6e91064d90 (+0x00001d90) 0x000000f8( 0K) c1 1 480 nMethod (active) isEmpty()Z > New: > > 0x00007f08adc94010 (+0x00000010) 0x00000150( 0K) c1 3 480 nMethod (deopt) nmethod > 0x00007f08adc94390 (+0x00000390) 0x000001b0( 0K) c1 3 480 nMethod (active) java.lang.String.isLatin1()Z > 0x00007f08adc94710 (+0x00000710) 0x00000258( 0K) c1 3 480 nMethod (active) jdk.internal.util.Preconditions.checkIndex(IILjava/util/function/BiFunction;)I > 0x00007f08adc94b90 (+0x00000b90) 0x000004e8( 1K) c1 3 480 nMethod (deopt) nmethod > 0x00007f08adc95310 (+0x00001310) 0x00000298( 0K) c1 3 480 nMethod (active) java.lang.StringLatin1.charAt([BI)C > 0x00007f08adc95790 (+0x00001790) 0x000001a0( 0K) c1 3 480 nMethod (active) java.lang.String.checkIndex(II)V > 0x00007f08adc95b10 (+0x00001b10) 0x00000170( 0K) c1 3 480 nMethod (active) java.lang.String.coder()B > 0x00007f08adc95e90 (+0x00001e90) 0x000003e8( 0K) c1 3 480 nMethod (active) java.lang.String.hashCode()I > 0x00007f08adc96490 (+0x00002490) 0x00000130( 0K) c1 3 480 nMethod (deopt) nmethod > 0x00007f08adc96790 (+0x00002790) 0x00000210( 0K) c1 3 480 nMethod (active) java.lang.String.length()I Thanks for reviewing @kelthuzadx and @TobiHartmann. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From dcubed at openjdk.java.net Tue Nov 2 20:31:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 2 Nov 2021 20:31:09 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2] In-Reply-To: References: Message-ID: <5KWuDZLS0qSZWRJ0qjnl-gO7uj2rrkw23jg24BXxTdo=.471e84eb-59eb-474f-81f5-037181d72f66@github.com> On Tue, 2 Nov 2021 01:07:30 GMT, Jakob Cornell wrote: >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect use of `receiveReplyFor' causing test failures @iklam - Can you review this fix? You were one of the original reviewers on: JDK-8271356 Modify jdb to treat an empty command as a repeat of the previous command Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From lucy at openjdk.java.net Tue Nov 2 20:58:20 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 2 Nov 2021 20:58:20 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed To me, the change looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From lucy at openjdk.java.net Tue Nov 2 20:58:21 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 2 Nov 2021 20:58:21 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 17:03:50 GMT, Evgeny Astigeevich wrote: >> src/hotspot/share/code/codeHeapState.cpp line 2340: >> >>> 2338: >>> 2339: Klass* klass = method->method_holder(); >>> 2340: assert(klass->is_loader_alive(), "must be alive"); >> >> Are you sure `klass` is always valid here and that its class loader has to be alive (i.e. the corresponding class hasn't been unloaded in the meantime)? >> >> In [https://bugs.openjdk.java.net/browse/JDK-8275729](JDK-8275729) you say that the Top50 list already has qualified names but as far as I know, that information is already collected in the aggregation step where it is safe. You now query this information in the reporting step. >> >> I know we had problems due to access to dead methods before (see [JDK-8219586: CodeHeap State Analytics processes dead nmethods](https://bugs.openjdk.java.net/browse/JDK-8219586) and I just want to make sure we don't re-introduce such problems. >> >> Maybe @RealLucy or @fisk can have an additional look? > > @simonis > The code is guarded by checks: > > // access nmethod and Method fields only if we own the CodeCache_lock. > // This fact is implicitly transported via nm != NULL. > if (nmethod_access_is_safe(nm)) { > ... > bool get_name = (cbType == nMethod_inuse) || (cbType == nMethod_notused); > ... > if (get_name) { > > I was thinking whether I should use `if (klass->is_loader_alive())` or `assert(klass->is_loader_alive())`. I chose the assert because if it is safe to access `Method` than its holder `Klass` must be alive. Hi, the code is safe. Not because of the checks cited by @eastig but because print_names() is only called if the required locks (Compile_lock and CodeCache_lock) have been continuously held since the aggregation step. See src/hotspot/share/compiler/compileBroker.cpp. A lot of effort has been spent to be less restrictive on print_names(), with no success. Thanks for the enhancement. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From iklam at openjdk.java.net Tue Nov 2 21:46:14 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 2 Nov 2021 21:46:14 GMT Subject: RFR: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" [v2] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 01:07:30 GMT, Jakob Cornell wrote: >> This will fix a few issues with the tests added in #5290: >> >> - [x] intermittent failures >> - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` > > Jakob Cornell has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect use of `receiveReplyFor' causing test failures LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6182 From kvn at openjdk.java.net Tue Nov 2 21:56:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 2 Nov 2021 21:56:20 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed The change caused failure in our testing: https://bugs.openjdk.java.net/browse/JDK-8276429 @eastig I will assign it to you ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From amenkov at openjdk.java.net Tue Nov 2 22:00:16 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 2 Nov 2021 22:00:16 GMT Subject: Integrated: 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) This pull request has now been integrated. Changeset: bb92fb02 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/bb92fb02ca8c5795989065a9037748dc39ed77db Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/5858 From kvn at openjdk.java.net Tue Nov 2 22:08:14 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 2 Nov 2021 22:08:14 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed I don't think we need this assert just to print klass's name ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From duke at openjdk.java.net Tue Nov 2 22:52:17 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 2 Nov 2021 22:52:17 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 22:05:01 GMT, Vladimir Kozlov wrote: > I don't think we need this assert just to print klass's name. May be follow the code pattern for method's name and signature. Agree. I'll submit PR with the code: Symbol* className = klass->name(); const char* classNameS = (className == nullptr) ? nullptr : className->external_name(); classNameS = (classNameS == nullptr) ? "" : classNameS; ast->print("%s.", classNameS); ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From kvn at openjdk.java.net Tue Nov 2 23:00:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 2 Nov 2021 23:00:17 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed Yes, I am currently testing similar fix: - Klass* klass = method->method_holder(); - assert(klass->is_loader_alive(), "must be alive"); + Klass* methHolder = method->method_holder(); + const char* methHolderS = (methHolder == NULL) ? NULL : methHolder->external_name(); + methHolderS = (methHolderS == NULL) ? "" : methHolderS; - ast->print("%s.", klass->external_name()); + ast->print("%s.", methHolderS); Note, failed test is `closed` so I have to run testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From duke at openjdk.java.net Tue Nov 2 23:08:19 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 2 Nov 2021 23:08:19 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: <0uEXYSu_8Y8V_aiyIRPVm3ZTvLRqeOFsULFvjHrl5n8=.ed87a21f-f34c-4950-b7f0-8ac32916c670@github.com> On Tue, 2 Nov 2021 22:57:23 GMT, Vladimir Kozlov wrote: > Yes, I am currently testing similar fix: > > ``` > - Klass* klass = method->method_holder(); > - assert(klass->is_loader_alive(), "must be alive"); > + Klass* methHolder = method->method_holder(); > + const char* methHolderS = (methHolder == NULL) ? NULL : methHolder->external_name(); > + methHolderS = (methHolderS == NULL) ? "" : methHolderS; > > - ast->print("%s.", klass->external_name()); > + ast->print("%s.", methHolderS); > ``` > > Note, failed test is `closed` so I have to run testing. Is NULL method holder an acceptable situation? Could it be a sign of a bug? BTW, `Klass::external_name()` returns `` if `Klass::name()` is `NULL`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From kvn at openjdk.java.net Tue Nov 2 23:20:14 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 2 Nov 2021 23:20:14 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: <0uEXYSu_8Y8V_aiyIRPVm3ZTvLRqeOFsULFvjHrl5n8=.ed87a21f-f34c-4950-b7f0-8ac32916c670@github.com> References: <0uEXYSu_8Y8V_aiyIRPVm3ZTvLRqeOFsULFvjHrl5n8=.ed87a21f-f34c-4950-b7f0-8ac32916c670@github.com> Message-ID: On Tue, 2 Nov 2021 23:03:22 GMT, Evgeny Astigeevich wrote: > Is NULL method holder an acceptable situation? Could it be a sign of a bug? You are right, all methods should have class holders. I just followed code pattern. > BTW, `Klass::external_name()` returns `` if `Klass::name()` is `NULL`. I see, you want to have the same string instead of ``. Reasonable. I will test your changes too. File PR and I will review and post testing results. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From kvn at openjdk.java.net Tue Nov 2 23:20:15 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 2 Nov 2021 23:20:15 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: References: Message-ID: <0L9rPQiskq-xc2eMFhRazjcZUFsuQW31_kVBwC47UkA=.6c0b5ec1-8696-47b5-872a-f478866bf0d0@github.com> On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich wrote: > This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. > Testing: > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed BTW, you need to update Copyright year in file. ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From dholmes at openjdk.java.net Wed Nov 3 01:31:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 3 Nov 2021 01:31:12 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Tue, 2 Nov 2021 17:26:41 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.cr2.patch Hi Dan, Generally seems okay but a couple of minor issues below. Thanks, David src/hotspot/share/runtime/handshake.cpp line 350: > 348: } > 349: > 350: void Handshake::execute(HandshakeClosure* hs_cl, ThreadsListHandle* tlh_p, JavaThread* target) { Nit: can we drop the `_p` part of `tlh_p` please. src/hotspot/share/runtime/thread.cpp line 446: > 444: Thread* current_thread = nullptr; > 445: if (checkTLHOnly) { > 446: current_thread = Thread::current(); This seems redundant due to line 463. You can just have a `if (!checkTLHOnly)` block here. src/hotspot/share/runtime/thread.cpp line 1764: > 1762: guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > 1763: "missing ThreadsListHandle in calling context."); > 1764: if (is_exiting()) { Can't we remove this the same as we did for `java_suspend()`? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4677 From rehn at openjdk.java.net Wed Nov 3 09:53:13 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 3 Nov 2021 09:53:13 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Tue, 2 Nov 2021 17:26:41 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.cr2.patch Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From rehn at openjdk.java.net Wed Nov 3 09:53:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 3 Nov 2021 09:53:14 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: <4_MJmDggUNVjRmG0UAKaSrsDgegEUKoGwmd_RtOQ0i0=.15aa9c7b-b865-4a90-829a-7f57027106aa@github.com> On Wed, 3 Nov 2021 01:19:21 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr2.patch > > src/hotspot/share/runtime/handshake.cpp line 350: > >> 348: } >> 349: >> 350: void Handshake::execute(HandshakeClosure* hs_cl, ThreadsListHandle* tlh_p, JavaThread* target) { > > Nit: can we drop the `_p` part of `tlh_p` please. Yes, please. > src/hotspot/share/runtime/thread.cpp line 1764: > >> 1762: guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), >> 1763: "missing ThreadsListHandle in calling context."); >> 1764: if (is_exiting()) { > > Can't we remove this the same as we did for `java_suspend()`? Yes, please ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Wed Nov 3 14:25:24 2021 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 3 Nov 2021 14:25:24 GMT Subject: RFR: 8275729: Qualified method names in CodeHeap Analytics In-Reply-To: <0L9rPQiskq-xc2eMFhRazjcZUFsuQW31_kVBwC47UkA=.6c0b5ec1-8696-47b5-872a-f478866bf0d0@github.com> References: <0L9rPQiskq-xc2eMFhRazjcZUFsuQW31_kVBwC47UkA=.6c0b5ec1-8696-47b5-872a-f478866bf0d0@github.com> Message-ID: <0Vys6k97aZS6oGOUF7u72xRU-rgnqkW0vMDM4zHd2l8=.c0a59ab6-8204-4d68-8123-ba1780f05045@github.com> On Tue, 2 Nov 2021 23:17:30 GMT, Vladimir Kozlov wrote: >> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be qualified. >> Testing: >> - `make test TEST="gtest"`: Passed >> - `make run-test TEST="tier1"`: Passed >> - `make run-test TEST="tier2"`: Passed >> - `make run-test TEST=serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java`: Passed > > BTW, you need to update Copyright year in file. @vnkozlov Created PR https://github.com/openjdk/jdk/pull/6234 ------------- PR: https://git.openjdk.java.net/jdk/pull/6200 From dcubed at openjdk.java.net Wed Nov 3 16:08:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 16:08:24 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: <4_MJmDggUNVjRmG0UAKaSrsDgegEUKoGwmd_RtOQ0i0=.15aa9c7b-b865-4a90-829a-7f57027106aa@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <4_MJmDggUNVjRmG0UAKaSrsDgegEUKoGwmd_RtOQ0i0=.15aa9c7b-b865-4a90-829a-7f57027106aa@github.com> Message-ID: On Wed, 3 Nov 2021 09:50:08 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 350: >> >>> 348: } >>> 349: >>> 350: void Handshake::execute(HandshakeClosure* hs_cl, ThreadsListHandle* tlh_p, JavaThread* target) { >> >> Nit: can we drop the `_p` part of `tlh_p` please. > > Yes, please. Fixed in handshake.[ch]pp. >> src/hotspot/share/runtime/thread.cpp line 1764: >> >>> 1762: guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), >>> 1763: "missing ThreadsListHandle in calling context."); >>> 1764: if (is_exiting()) { >> >> Can't we remove this the same as we did for `java_suspend()`? > > Yes, please The rationale for removing the is_exiting() check from `java_suspend()` was that it was redundant because the handshake code detected and handled the `is_exiting()` case so we didn't need to do that work twice. If we look at `HandshakeState::resume()` there is no logic for detecting or handling the possibility of an exiting thread. That being said, we have to look closer at what `HandshakeState::resume()` does and whether that logic can be harmful if executed on an exiting thread. Here's the code: bool HandshakeState::resume() { if (!is_suspended()) { return false; } MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); if (!is_suspended()) { assert(!_handshakee->is_suspended(), "cannot be suspended without a suspend request"); return false; } // Resume the thread. set_suspended(false); _lock.notify(); return true; } I'm not seeing anything in `HandshakeState::resume()` that worries me with respect to an exiting thread. Of course, the proof is in the testing so I'll rerun the usual testing after deleting that code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Wed Nov 3 16:08:25 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 16:08:25 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Wed, 3 Nov 2021 01:21:50 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr2.patch > > src/hotspot/share/runtime/thread.cpp line 446: > >> 444: Thread* current_thread = nullptr; >> 445: if (checkTLHOnly) { >> 446: current_thread = Thread::current(); > > This seems redundant due to line 463. You can just have a `if (!checkTLHOnly)` block here. I suspect that the way that git is displaying the diffs is confusing you. We need `current_thread` set if we get to line 474 so we have to init `current_thread` on line 446 for the `checkTLHOnly == true` case and on line 463 for the `checkTLHOnly == false` case. I could simplify the logic by always setting current thread when it is declared on 444, but I was trying to avoid the call to `Thread::current()` until I actually needed it. I thought `Thread::current()` can be expensive. Is this no longer the case? ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Wed Nov 3 16:25:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 16:25:09 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. Ping! Any takers? ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From stuefe at openjdk.java.net Wed Nov 3 17:55:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Nov 2021 17:55:11 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. Hi Daniel, looks good. Small remarks below. I leave it up to you if you take my suggestions. Cheers, Thomas src/hotspot/os/bsd/os_bsd.cpp line 902: > 900: return false; > 901: } > 902: #endif We use dladdr() in several places in this code. I wonder whether it would make sense to fix all of those with a wrapper instead: static int my_dladdr(const void* addr, Dl_info* info) { if (addr != (void*)-1) { return dladdr(addr, info); } else { // add comment here return 0; } } #define dladdr my_dladdr src/hotspot/os/bsd/os_bsd.cpp line 918: > 916: // ranges like ELF. That makes sense since Mach-O can contain binaries for > 917: // than one instruction set so there can be more than one address range for > 918: // each "file". Small nit, it seems confusing to have a Mac-specific comment in the BSD section. Maybe this would be better in MachDecoder? E.g. implement the 6-arg version of decode() but stubbed out returning false, and with your comment there. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From duke at openjdk.java.net Wed Nov 3 18:21:22 2021 From: duke at openjdk.java.net (Jakob Cornell) Date: Wed, 3 Nov 2021 18:21:22 GMT Subject: Integrated: 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 04:39:27 GMT, Jakob Cornell wrote: > This will fix a few issues with the tests added in #5290: > > - [x] intermittent failures > - [x] tests should use `failure` method to report problems rather than throwing `AssertionError` This pull request has now been integrated. Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 Stats: 25 lines in 2 files changed: 1 ins; 0 del; 24 mod 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/6182 From dcubed at openjdk.java.net Wed Nov 3 19:23:11 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 19:23:11 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. @tstuefe - Thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Wed Nov 3 19:23:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 19:23:13 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 17:49:40 GMT, Thomas Stuefe wrote: >> macOS12 has changed the dladdr() function to accept "-1" as a valid address and >> we have functions that use dladdr() to convert DLL addresses into function or >> library names. We also have a gtest that verifies that "-1" is not a valid value to use >> as a symbol address. >> >> As you might imagine, existing code that uses `os::dll_address_to_function_name()` >> or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) >> if an `addr` parameter of `-1` was allowed to be used. >> >> I've also made two cleanup changes as part of this fix: >> >> 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should >> be properly `#ifdef`'ed. There is also some code that makes sense for ELF format >> files, but not for Mach-O format files so that code needs to be excluded on macOS. >> >> 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an >> `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code >> base so I'd like to fix it with this bug ID since I'm in related areas. >> >> This fix has been tested with Mach5 Tier[1-6]. > > src/hotspot/os/bsd/os_bsd.cpp line 902: > >> 900: return false; >> 901: } >> 902: #endif > > We use dladdr() in several places in this code. I wonder whether it would make sense to fix all of those with a wrapper instead: > > static int my_dladdr(const void* addr, Dl_info* info) { > if (addr != (void*)-1) { > return dladdr(addr, info); > } else { > // add comment here > return 0; > } > } > #define dladdr my_dladdr I'll take a look at the other calls to dladdr(). I'm trying to limit what I change here to things that actually failed in our test on macOS12 on X64 and aarch64. > src/hotspot/os/bsd/os_bsd.cpp line 918: > >> 916: // ranges like ELF. That makes sense since Mach-O can contain binaries for >> 917: // than one instruction set so there can be more than one address range for >> 918: // each "file". > > Small nit, it seems confusing to have a Mac-specific comment in the BSD section. > > Maybe this would be better in MachDecoder? E.g. implement the 6-arg version of decode() but stubbed out returning false, and with your comment there. It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS port was built on top of the BSD port and the BSD port was built by copying a LOT of code from Linux into BSD specific files with modifications as needed. If I pushed this change down into MachDecoder, then I would have to lose the `ShouldNotReachHere()` call in order to not assert in non-release bits. I don't think I want to do that since this may not be the only place that calls the 6-arg version of decode(). ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Wed Nov 3 19:30:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 3 Nov 2021 19:30:12 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 19:08:38 GMT, Daniel D. Daugherty wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 902: >> >>> 900: return false; >>> 901: } >>> 902: #endif >> >> We use dladdr() in several places in this code. I wonder whether it would make sense to fix all of those with a wrapper instead: >> >> static int my_dladdr(const void* addr, Dl_info* info) { >> if (addr != (void*)-1) { >> return dladdr(addr, info); >> } else { >> // add comment here >> return 0; >> } >> } >> #define dladdr my_dladdr > > I'll take a look at the other calls to dladdr(). I'm trying to limit what I change > here to things that actually failed in our test on macOS12 on X64 and aarch64. I took a quick look at the other calls to `dladdr()` in src/hotspot/os/bsd/os_bsd.cpp and I'm not comfortable with changing those uses without having a specific test case that I can use to investigate those code paths. We are fairly early in our testing on macOS12 so I may run into a reason to revisit this choice down the road. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From gziemski at openjdk.java.net Wed Nov 3 22:08:11 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 3 Nov 2021 22:08:11 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. Looks good, just a few optional nitpicks that I personally would have done, if it were me doing the change. src/hotspot/os/bsd/os_bsd.cpp line 929: > 927: #endif > 928: > 929: #if defined(__APPLE__) Why not just do: `#else` here instead and collapse these 3 lines into 1? src/hotspot/os/bsd/os_bsd.cpp line 930: > 928: > 929: #if defined(__APPLE__) > 930: char localbuf[MACH_MAXSYMLEN]; This `__APPLE__` section is the only one, that I can see, using `MACH_MAXSYMLEN`, why not move: #if defined(__APPLE__) #define MACH_MAXSYMLEN 256 #endif here (i.e. just the `#define MACH_MAXSYMLEN 256` and minimize the need for` __APPLE__` sections? src/hotspot/os/bsd/os_bsd.cpp line 964: > 962: if (offset) *offset = -1; > 963: return false; > 964: } Do we need this here? Wouldn't the earlier call to `Decoder::decode(addr, localbuf, MACH_MAXSYMLEN, offset, dlinfo.dli_fbase))` catch this with `ShouldNotReachHere`? ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/6193 From ysuenaga at openjdk.java.net Thu Nov 4 00:53:38 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 4 Nov 2021 00:53:38 GMT Subject: RFR: 8276615: Update CR number of some tests in ProblemList-zgc.txt Message-ID: <5w9ycLvgNIj1XCcJ3F3uPtRXQzeHjdVJrC3zg33GbAg=.136de865-edab-4d5a-ac9d-64726dfd3991@github.com> Following tests are referred to [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), however it has been closed due to all subtasks were resolved. * resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java * serviceability/sa/CDSJMapClstats.java * serviceability/sa/ClhsdbJhisto.java We will work these problems in [JDK-8276539](https://bugs.openjdk.java.net/browse/JDK-8276539), so we need to update CR number of them. ------------- Commit messages: - 8276615: Update CR number of some tests in ProblemList-zgc.txt Changes: https://git.openjdk.java.net/jdk/pull/6244/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6244&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276615 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6244.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6244/head:pull/6244 PR: https://git.openjdk.java.net/jdk/pull/6244 From dholmes at openjdk.java.net Thu Nov 4 01:21:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Nov 2021 01:21:16 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Wed, 3 Nov 2021 15:45:06 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 446: >> >>> 444: Thread* current_thread = nullptr; >>> 445: if (checkTLHOnly) { >>> 446: current_thread = Thread::current(); >> >> This seems redundant due to line 463. You can just have a `if (!checkTLHOnly)` block here. > > I suspect that the way that git is displaying the diffs is confusing you. > > We need `current_thread` set if we get to line 474 so we have to init > `current_thread` on line 446 for the `checkTLHOnly == true` case and > on line 463 for the `checkTLHOnly == false` case. > > I could simplify the logic by always setting current thread when it is > declared on 444, but I was trying to avoid the call to `Thread::current()` > until I actually needed it. I thought `Thread::current()` can be expensive. > Is this no longer the case? Sorry I missed that line 463 is still within the else from line 447. Thread::current() is a compiler-defined thread-local access so should be relatively cheap these days, but I have no numbers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dholmes at openjdk.java.net Thu Nov 4 01:21:16 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Nov 2021 01:21:16 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <4_MJmDggUNVjRmG0UAKaSrsDgegEUKoGwmd_RtOQ0i0=.15aa9c7b-b865-4a90-829a-7f57027106aa@github.com> Message-ID: On Wed, 3 Nov 2021 16:05:21 GMT, Daniel D. Daugherty wrote: >> Yes, please > > The rationale for removing the is_exiting() check from `java_suspend()` was that it > was redundant because the handshake code detected and handled the `is_exiting()` > case so we didn't need to do that work twice. > > If we look at `HandshakeState::resume()` there is no logic for detecting or handling > the possibility of an exiting thread. That being said, we have to look closer at what > `HandshakeState::resume()` does and whether that logic can be harmful if executed > on an exiting thread. > > Here's the code: > > bool HandshakeState::resume() { > if (!is_suspended()) { > return false; > } > MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); > if (!is_suspended()) { > assert(!_handshakee->is_suspended(), "cannot be suspended without a suspend request"); > return false; > } > // Resume the thread. > set_suspended(false); > _lock.notify(); > return true; > } > > > I'm not seeing anything in `HandshakeState::resume()` that > worries me with respect to an exiting thread. Of course, the > proof is in the testing so I'll rerun the usual testing after > deleting that code. A suspended thread cannot be exiting - else the suspend logic is broken. So, given you can call `resume()` on a not-suspended thread, as long as the handshake code checks for `is_supended()` (which it does) then no explicit `is_exiting` check is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dholmes at openjdk.java.net Thu Nov 4 01:54:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Nov 2021 01:54:11 GMT Subject: RFR: 8276615: Update CR number of some tests in ProblemList-zgc.txt In-Reply-To: <5w9ycLvgNIj1XCcJ3F3uPtRXQzeHjdVJrC3zg33GbAg=.136de865-edab-4d5a-ac9d-64726dfd3991@github.com> References: <5w9ycLvgNIj1XCcJ3F3uPtRXQzeHjdVJrC3zg33GbAg=.136de865-edab-4d5a-ac9d-64726dfd3991@github.com> Message-ID: On Thu, 4 Nov 2021 00:46:49 GMT, Yasumasa Suenaga wrote: > Following tests are referred to [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), however it has been closed due to all subtasks were resolved. > > * resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > * serviceability/sa/CDSJMapClstats.java > * serviceability/sa/ClhsdbJhisto.java > > We will work these problems in [JDK-8276539](https://bugs.openjdk.java.net/browse/JDK-8276539), so we need to update CR number of them. Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6244 From iklam at openjdk.java.net Thu Nov 4 02:15:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 4 Nov 2021 02:15:45 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: 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). Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments - 8275185: Remove dead code and clean up jvmstat LocalVmManager ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5923/files - new: https://git.openjdk.java.net/jdk/pull/5923/files/c2f3937b..bbeb7c16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5923&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5923&range=00-01 Stats: 43203 lines in 1054 files changed: 33107 ins; 6126 del; 3970 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 iklam at openjdk.java.net Thu Nov 4 02:15:47 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 4 Nov 2021 02:15:47 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: <9nB_cwTM3coW0cRQYFJT8EZDtpCsWO-IP6f7rxDkcgw=.c9578e0b-0cee-49b4-816a-12e0ba1c30ca@github.com> References: <9nB_cwTM3coW0cRQYFJT8EZDtpCsWO-IP6f7rxDkcgw=.c9578e0b-0cee-49b4-816a-12e0ba1c30ca@github.com> Message-ID: On Wed, 20 Oct 2021 02:23:25 GMT, Serguei Spitsyn wrote: > 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. Do we really care about pre 1.4.2 formats? If so, what is the way to test it? 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 I am not sure about 1.4.2 formats. I guess we don't really care, but we should probably remove it in a separate RFE. I am trying to keep this PR from having any functional changes, and will just remove dead code. For testing, I am running tiers 1-4. Will that be enough? I'll ping the performance team. Thanks - Ioi ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From iklam at openjdk.java.net Thu Nov 4 02:15:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 4 Nov 2021 02:15:49 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 07:48:05 GMT, Kevin Walls wrote: > 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-) Hi Kevin, thanks for the review. I've moved the filename patterns back to PerfDataFile.java as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From iklam at openjdk.java.net Thu Nov 4 02:15:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 4 Nov 2021 02:15:55 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: <6ub-vuz81sCCxqUjDb5aGCYT4neIn5bJi8hp2jLYM0Q=.8e0dda37-e8ae-4427-b583-46d552493976@github.com> On Tue, 19 Oct 2021 22:02:58 GMT, Chris Plummer wrote: >> Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code >> - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments >> - 8275185: Remove dead code and clean up jvmstat LocalVmManager > > 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. I restored this line to use PerfDataFile.tmpFileNamePattern, as before my changes. Yes, that's an odd way of naming a file. > 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]+` Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From cjplummer at openjdk.java.net Thu Nov 4 03:48:18 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 4 Nov 2021 03:48:18 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 02:15:45 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). > > Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code > - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments > - 8275185: Remove dead code and clean up jvmstat LocalVmManager Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From ysuenaga at openjdk.java.net Thu Nov 4 04:37:17 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 4 Nov 2021 04:37:17 GMT Subject: Integrated: 8276615: Update CR number of some tests in ProblemList-zgc.txt In-Reply-To: <5w9ycLvgNIj1XCcJ3F3uPtRXQzeHjdVJrC3zg33GbAg=.136de865-edab-4d5a-ac9d-64726dfd3991@github.com> References: <5w9ycLvgNIj1XCcJ3F3uPtRXQzeHjdVJrC3zg33GbAg=.136de865-edab-4d5a-ac9d-64726dfd3991@github.com> Message-ID: On Thu, 4 Nov 2021 00:46:49 GMT, Yasumasa Suenaga wrote: > Following tests are referred to [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), however it has been closed due to all subtasks were resolved. > > * resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > * serviceability/sa/CDSJMapClstats.java > * serviceability/sa/ClhsdbJhisto.java > > We will work these problems in [JDK-8276539](https://bugs.openjdk.java.net/browse/JDK-8276539), so we need to update CR number of them. This pull request has now been integrated. Changeset: 558ee40a Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6244 From stuefe at openjdk.java.net Thu Nov 4 05:16:14 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Nov 2021 05:16:14 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. Marked as reviewed by stuefe (Reviewer). Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From stuefe at openjdk.java.net Thu Nov 4 05:16:14 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Nov 2021 05:16:14 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 19:27:32 GMT, Daniel D. Daugherty wrote: > I took a quick look at the other calls to `dladdr()` in src/hotspot/os/bsd/os_bsd.cpp and I'm not comfortable with changing those uses without having a specific test case that I can use to investigate those code paths. > > We are fairly early in our testing on macOS12 so I may run into a reason to revisit this choice down the road. Okay! ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From stuefe at openjdk.java.net Thu Nov 4 05:16:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Nov 2021 05:16:15 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 19:19:11 GMT, Daniel D. Daugherty wrote: > It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS port was built on top of the BSD port and the BSD port was built by copying a LOT of code from Linux into BSD specific files with modifications as needed. I always wondered whether anyone actually builds the BSDs in head. I assume Oracle does not, right? I know there are downstream porters somewhere but only for old releases, or? > > If I pushed this change down into MachDecoder, then I would have to lose the `ShouldNotReachHere()` call in order to not assert in non-release bits. I don't think I want to do that since this may not be the only place that calls the 6-arg version of decode(). Fair enough, thanks for the clarification. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From chris.plummer at oracle.com Thu Nov 4 06:09:43 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 3 Nov 2021 23:09:43 -0700 Subject: [External] : Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd In-Reply-To: <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> Message-ID: An HTML attachment was scrubbed... URL: From redestad at openjdk.java.net Thu Nov 4 10:34:24 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 4 Nov 2021 10:34:24 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 02:15:45 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). > > Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code > - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments > - 8275185: Remove dead code and clean up jvmstat LocalVmManager Supporting 1.4.1 hsperfdata seems pointless at this point, so I support a removal of that code. It also seems reasonable to do as a follow-up, as @iklam suggests, rather than shifting the scope this PR. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5923 From ihse at openjdk.java.net Thu Nov 4 10:51:27 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 10:51:27 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code Message-ID: I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. ------------- Commit messages: - 8276628: Use blessed modifier order in serviceability code Changes: https://git.openjdk.java.net/jdk/pull/6249/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6249&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276628 Stats: 235 lines in 89 files changed: 0 ins; 0 del; 235 mod Patch: https://git.openjdk.java.net/jdk/pull/6249.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6249/head:pull/6249 PR: https://git.openjdk.java.net/jdk/pull/6249 From kevinw at openjdk.java.net Thu Nov 4 11:24:15 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 4 Nov 2021 11:24:15 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 02:15:45 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). > > Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code > - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments > - 8275185: Remove dead code and clean up jvmstat LocalVmManager Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From kevinw at openjdk.java.net Thu Nov 4 11:24:15 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 4 Nov 2021 11:24:15 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 02:07:42 GMT, Ioi Lam wrote: > ...moved the filename patterns back to PerfDataFile.java... Thanks, looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From dholmes at openjdk.java.net Thu Nov 4 12:23:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 4 Nov 2021 12:23:23 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Looks fine to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6249 From stuefe at openjdk.java.net Thu Nov 4 13:33:28 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Nov 2021 13:33:28 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Message-ID: `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. This patch removes the display of reflection targets from these commands as well as associated helper code and tests. I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. Tests: GHAs, manually testing the commands. ------------- Commit messages: - Remove reflection invocation target printing from VM.metaspace, VM.classloaders, VM.class_hierarchy Changes: https://git.openjdk.java.net/jdk/pull/6257/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6257&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272065 Stats: 368 lines in 8 files changed: 0 ins; 367 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6257/head:pull/6257 PR: https://git.openjdk.java.net/jdk/pull/6257 From lmesnik at openjdk.java.net Thu Nov 4 14:26:10 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 4 Nov 2021 14:26:10 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From cjplummer at openjdk.java.net Thu Nov 4 16:03:21 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 4 Nov 2021 16:03:21 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Copyright updates? ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From coleenp at openjdk.java.net Thu Nov 4 16:31:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Nov 2021 16:31:08 GMT Subject: RFR: 8276173: Clean up and remove unneeded casts in HeapDumper [v2] In-Reply-To: References: <7UWZhgvlTjtIEiL6xV0hAVdm5elGVpn8DUliJ5Xvt90=.0f5ca378-5579-45ad-814b-61d0f9d83865@github.com> Message-ID: <4h496rFgUyiO_4heJJccTkOgcXuUx2AOqYGaiVGAhyE=.6c91d638-fc24-44da-ba4b-bd9cfab45981@github.com> On Tue, 2 Nov 2021 19:25:40 GMT, Leo Korinth wrote: >> HeapDumper does a lot of unneeded casts. Some arguments should be const. Headers are not correctly sorted. Comment about identifier size on Windows and Solaris is not true. >> >> First I cleaned up casting in the "union casting", but then I decided it was better to create a temporary bit_cast that we can use until we get the proper one in c++20. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests This looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6211 From dcubed at openjdk.java.net Thu Nov 4 17:02:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:02:48 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v11] 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: 8249004.cr3.patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/3e1d1b06..86fcdfbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=09-10 Stats: 10 lines in 3 files changed: 0 ins; 4 del; 6 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 Nov 4 17:02:51 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:02:51 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: 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 and @robehn - Thanks for your reviews on the previous version (8249004.cr2.patch). Mach5 Tier[1-5] testing has finished and looks good; Mach5 Tier[678] are still running. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From mchung at openjdk.java.net Thu Nov 4 17:05:22 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 4 Nov 2021 17:05:22 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote: > `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. > > This patch removes the display of reflection targets from these commands as well as associated helper code and tests. > > I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. > > The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. > > Tests: GHAs, manually testing the commands. Looks good to me. Thanks for following this up. The new implementation does not spin any new class loader and so I don't think jcmd needs to extend its support for the new implementation using method handles. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6257 From ihse at openjdk.java.net Thu Nov 4 17:07:24 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 17:07:24 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 15:59:48 GMT, Chris Plummer wrote: >> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > Copyright updates? @plummercj That's really kind of an edge case, considering the triviality of these changes. But yes, the norm in the JDK is to update the copyright year for all changes, so you're right, I should do that. (And we *really* ought to wrangle free some resources to write tooling for us to do all the copyright dances...) ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From dcubed at openjdk.java.net Thu Nov 4 17:09:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:09:14 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Thu, 4 Nov 2021 01:16:03 GMT, David Holmes wrote: >> I suspect that the way that git is displaying the diffs is confusing you. >> >> We need `current_thread` set if we get to line 474 so we have to init >> `current_thread` on line 446 for the `checkTLHOnly == true` case and >> on line 463 for the `checkTLHOnly == false` case. >> >> I could simplify the logic by always setting current thread when it is >> declared on 444, but I was trying to avoid the call to `Thread::current()` >> until I actually needed it. I thought `Thread::current()` can be expensive. >> Is this no longer the case? > > Sorry I missed that line 463 is still within the else from line 447. > > Thread::current() is a compiler-defined thread-local access so should be relatively cheap these days, but I have no numbers. I'm really tempted to go ahead and change it to always set current thread when it is declared and then clean things up a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Thu Nov 4 17:09:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:09:14 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <4_MJmDggUNVjRmG0UAKaSrsDgegEUKoGwmd_RtOQ0i0=.15aa9c7b-b865-4a90-829a-7f57027106aa@github.com> Message-ID: On Thu, 4 Nov 2021 01:18:23 GMT, David Holmes wrote: >> The rationale for removing the is_exiting() check from `java_suspend()` was that it >> was redundant because the handshake code detected and handled the `is_exiting()` >> case so we didn't need to do that work twice. >> >> If we look at `HandshakeState::resume()` there is no logic for detecting or handling >> the possibility of an exiting thread. That being said, we have to look closer at what >> `HandshakeState::resume()` does and whether that logic can be harmful if executed >> on an exiting thread. >> >> Here's the code: >> >> bool HandshakeState::resume() { >> if (!is_suspended()) { >> return false; >> } >> MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); >> if (!is_suspended()) { >> assert(!_handshakee->is_suspended(), "cannot be suspended without a suspend request"); >> return false; >> } >> // Resume the thread. >> set_suspended(false); >> _lock.notify(); >> return true; >> } >> >> >> I'm not seeing anything in `HandshakeState::resume()` that >> worries me with respect to an exiting thread. Of course, the >> proof is in the testing so I'll rerun the usual testing after >> deleting that code. > > A suspended thread cannot be exiting - else the suspend logic is broken. So, given you can call `resume()` on a not-suspended thread, as long as the handshake code checks for `is_supended()` (which it does) then no explicit `is_exiting` check is needed. Agreed! I have to keep reminding myself that with handshake based suspend and resume, we just don't have the same races with exiting threads that we used to have. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From hseigel at openjdk.java.net Thu Nov 4 17:23:15 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 4 Nov 2021 17:23:15 GMT Subject: RFR: 8276173: Clean up and remove unneeded casts in HeapDumper [v2] In-Reply-To: References: <7UWZhgvlTjtIEiL6xV0hAVdm5elGVpn8DUliJ5Xvt90=.0f5ca378-5579-45ad-814b-61d0f9d83865@github.com> Message-ID: <-dUhq2cF7iPBpF_PDhmgKbBKqVEwzn3wwQEgXAOugA0=.3363d4bd-a242-4348-b7c9-59f9d599dc7e@github.com> On Tue, 2 Nov 2021 19:25:40 GMT, Leo Korinth wrote: >> HeapDumper does a lot of unneeded casts. Some arguments should be const. Headers are not correctly sorted. Comment about identifier size on Windows and Solaris is not true. >> >> First I cleaned up casting in the "union casting", but then I decided it was better to create a temporary bit_cast that we can use until we get the proper one in c++20. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests Looks good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6211 From dcubed at openjdk.java.net Thu Nov 4 17:29:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:29:13 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. @tstuefe - Thanks for closing the loop on my previous replies. @gerard-ziemski - Thanks for the review! I'm going to make more tweaks to this fix and will update the PR after my test cycle is complete. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Thu Nov 4 17:29:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:29:14 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 05:12:32 GMT, Thomas Stuefe wrote: >> It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS >> port was built on top of the BSD port and the BSD port was built by copying a LOT >> of code from Linux into BSD specific files with modifications as needed. >> >> If I pushed this change down into MachDecoder, then I would have to lose the >> `ShouldNotReachHere()` call in order to not assert in non-release bits. I don't >> think I want to do that since this may not be the only place that calls the >> 6-arg version of decode(). > >> It's actually fairly common to have Mac-specific stuff in the BSD files. The macOS port was built on top of the BSD port and the BSD port was built by copying a LOT of code from Linux into BSD specific files with modifications as needed. > > I always wondered whether anyone actually builds the BSDs in head. I assume Oracle does not, right? I know there are downstream porters somewhere but only for old releases, or? > >> >> If I pushed this change down into MachDecoder, then I would have to lose the `ShouldNotReachHere()` call in order to not assert in non-release bits. I don't think I want to do that since this may not be the only place that calls the 6-arg version of decode(). > > Fair enough, thanks for the clarification. Oracle does not build BSD in head. At one point, Dmitry Samersoff used to build BSD in his lab, but I don't know if he still does that. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Thu Nov 4 17:29:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:29:13 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: <7v_HGFXA0_lVUySP0r7pz3pUMljRMo99T60K1ALO4mc=.6887379c-9fa1-407e-ba1f-c7ca5ca08171@github.com> On Thu, 4 Nov 2021 05:12:48 GMT, Thomas Stuefe wrote: >> I took a quick look at the other calls to `dladdr()` in src/hotspot/os/bsd/os_bsd.cpp >> and I'm not comfortable with changing those uses without having a specific test >> case that I can use to investigate those code paths. >> >> We are fairly early in our testing on macOS12 so I may run into a reason to revisit >> this choice down the road. > >> I took a quick look at the other calls to `dladdr()` in src/hotspot/os/bsd/os_bsd.cpp and I'm not comfortable with changing those uses without having a specific test case that I can use to investigate those code paths. >> >> We are fairly early in our testing on macOS12 so I may run into a reason to revisit this choice down the road. > > Okay! I've had a chance to think about this overnight and I'm not liking my duplication of code so I'm going to look at adding a wrapper that is called by the two calls sites where know I need the special handling. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Thu Nov 4 17:29:16 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 17:29:16 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 21:14:17 GMT, Gerard Ziemski wrote: >> macOS12 has changed the dladdr() function to accept "-1" as a valid address and >> we have functions that use dladdr() to convert DLL addresses into function or >> library names. We also have a gtest that verifies that "-1" is not a valid value to use >> as a symbol address. >> >> As you might imagine, existing code that uses `os::dll_address_to_function_name()` >> or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) >> if an `addr` parameter of `-1` was allowed to be used. >> >> I've also made two cleanup changes as part of this fix: >> >> 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should >> be properly `#ifdef`'ed. There is also some code that makes sense for ELF format >> files, but not for Mach-O format files so that code needs to be excluded on macOS. >> >> 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an >> `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code >> base so I'd like to fix it with this bug ID since I'm in related areas. >> >> This fix has been tested with Mach5 Tier[1-6]. > > src/hotspot/os/bsd/os_bsd.cpp line 929: > >> 927: #endif >> 928: >> 929: #if defined(__APPLE__) > > Why not just do: > > `#else` > > here instead and collapse these 3 lines into 1? Hmmm... I'll take a look at doing that. > src/hotspot/os/bsd/os_bsd.cpp line 930: > >> 928: >> 929: #if defined(__APPLE__) >> 930: char localbuf[MACH_MAXSYMLEN]; > > This `__APPLE__` section is the only one, that I can see, using `MACH_MAXSYMLEN`, why not move: > > > #if defined(__APPLE__) > #define MACH_MAXSYMLEN 256 > #endif > > > here (i.e. just the `#define MACH_MAXSYMLEN 256` and minimize the need for` __APPLE__` sections? Hmmm.... I'll take a look at cleaning this up a bit. > src/hotspot/os/bsd/os_bsd.cpp line 964: > >> 962: if (offset) *offset = -1; >> 963: return false; >> 964: } > > Do we need this here? Wouldn't the earlier call to `Decoder::decode(addr, localbuf, MACH_MAXSYMLEN, offset, dlinfo.dli_fbase))` catch this with `ShouldNotReachHere`? That's the 5-parameter version of decode() and it doesn't have `ShouldNotReachHere`. So if that code site is called and returns `false`, then we get into `dll_address_to_library_name()` and reach this `dladdr()` call which will accept the "-1"... ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From ihse at openjdk.java.net Thu Nov 4 17:36:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 4 Nov 2021 17:36:52 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code [v2] In-Reply-To: References: Message-ID: > I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6249/files - new: https://git.openjdk.java.net/jdk/pull/6249/files/cf5db105..8a5ff8a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6249&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6249&range=00-01 Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/6249.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6249/head:pull/6249 PR: https://git.openjdk.java.net/jdk/pull/6249 From cjplummer at openjdk.java.net Thu Nov 4 18:08:11 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 4 Nov 2021 18:08:11 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code [v2] In-Reply-To: References: Message-ID: <-iSUoILuWhTb2AgWH-HGAsEm4Nvo8Fl6NIVaiFTY3Lo=.5ec41a0d-e7f3-4f57-b651-7c1971f48e3c@github.com> On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie wrote: >> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update copyright year Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From stuefe at openjdk.java.net Thu Nov 4 18:33:12 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 4 Nov 2021 18:33:12 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 17:02:05 GMT, Mandy Chung wrote: > Looks good to me. Thanks for following this up. The new implementation does not spin any new class loader and so I don't think jcmd needs to extend its support for the new implementation using method handles. Thank you Mandy! ------------- PR: https://git.openjdk.java.net/jdk/pull/6257 From coleenp at openjdk.java.net Thu Nov 4 19:16:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Nov 2021 19:16:09 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote: > `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. > > This patch removes the display of reflection targets from these commands as well as associated helper code and tests. > > I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. > > The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. > > Tests: GHAs, manually testing the commands. Yes, looks good to me also. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6257 From coleenp at openjdk.java.net Thu Nov 4 21:48:12 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Nov 2021 21:48:12 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Tue, 2 Nov 2021 17:26:41 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.cr2.patch Sorry for such a long delay looking at this. I had a couple questions and a suggestion. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Thu Nov 4 21:48:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Nov 2021 21:48:13 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: On Fri, 15 Oct 2021 21:34:50 GMT, Daniel D. Daugherty wrote: >> 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. Should the ThreadsListHandle protect JvmtiThreadState::first also? If state->next() needs it why doesn't the first entry need this? There's no atomic load on the _head field. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Thu Nov 4 21:48:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 4 Nov 2021 21:48:13 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Thu, 4 Nov 2021 17:02:59 GMT, Daniel D. Daugherty wrote: >> Sorry I missed that line 463 is still within the else from line 447. >> >> Thread::current() is a compiler-defined thread-local access so should be relatively cheap these days, but I have no numbers. > > I'm really tempted to go ahead and change it to always set > current thread when it is declared and then clean things up a bit. Yes, ^ that might make the logic easier to follow. I can't figure out what checkTLSOnly means. Could it be refactored into a different function like check_TLS() and then call it in the place where you pass true instead of is_JavaThread_protected? Does checkTLSOnly skip a lot of these checks? ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Thu Nov 4 22:59:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 22:59:39 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: References: Message-ID: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: 8273967.cr1.patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6193/files - new: https://git.openjdk.java.net/jdk/pull/6193/files/f57d7f0d..ecb230d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6193&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6193&range=00-01 Stats: 48 lines in 1 file changed: 16 ins; 28 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6193/head:pull/6193 PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Thu Nov 4 22:59:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 22:59:42 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 05:13:29 GMT, Thomas Stuefe wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273967.cr1.patch > > Marked as reviewed by stuefe (Reviewer). @tstuefe and @gerard-ziemski - please re-review when you get the chance. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Thu Nov 4 22:59:43 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 4 Nov 2021 22:59:43 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. This version has been tested with Mach5 Tier1 and with runs of the specific tests using release and debug bits on macosx-aarch64 and macosx-x64 test machines running macOS12. ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dholmes at openjdk.java.net Fri Nov 5 00:38:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Nov 2021 00:38:13 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code [v2] In-Reply-To: References: Message-ID: <7jntohY4FpQYK4L1W1l8wkvamKZhSTjXqtS0CEYIJ7k=.0e5e17bf-d6e5-41dc-8ffd-e30fb4803a29@github.com> On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie wrote: >> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update copyright year Good catch on copyright updates @plummercj ! We always have to update when we modify a file - the one exception is changing the wording of the copyright notice itself. Looks good. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6249 From iklam at openjdk.java.net Fri Nov 5 04:40:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 5 Nov 2021 04:40:18 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 03:44:43 GMT, Chris Plummer wrote: >> Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code >> - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments >> - 8275185: Remove dead code and clean up jvmstat LocalVmManager > > Marked as reviewed by cjplummer (Reviewer). Thanks @plummercj @kevinjwalls @cl4es for the review. I filed https://bugs.openjdk.java.net/browse/JDK-8276687 to remove the JDK 1.4.1 support. Passed Oracle CI tiers1-4 ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From iklam at openjdk.java.net Fri Nov 5 04:40:19 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 5 Nov 2021 04:40:19 GMT Subject: Integrated: 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). This pull request has now been integrated. Changeset: 8e17ce00 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 Stats: 296 lines in 2 files changed: 9 ins; 255 del; 32 mod 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From dholmes at openjdk.java.net Fri Nov 5 05:03:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Nov 2021 05:03:09 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote: > `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. > > This patch removes the display of reflection targets from these commands as well as associated helper code and tests. > > I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. > > The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. > > Tests: GHAs, manually testing the commands. I never realized we needed special handling for these classloaders so I'm glad to see this gone too. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6257 From stuefe at openjdk.java.net Fri Nov 5 05:19:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 5 Nov 2021 05:19:11 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> References: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> Message-ID: <-CAS0w-b0QThAGOMqni0ZYYcRyjEr2dcSP13fAy7__w=.b03d740c-22e2-47e8-a669-b3799e6478b6@github.com> On Thu, 4 Nov 2021 22:59:39 GMT, Daniel D. Daugherty wrote: >> macOS12 has changed the dladdr() function to accept "-1" as a valid address and >> we have functions that use dladdr() to convert DLL addresses into function or >> library names. We also have a gtest that verifies that "-1" is not a valid value to use >> as a symbol address. >> >> As you might imagine, existing code that uses `os::dll_address_to_function_name()` >> or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) >> if an `addr` parameter of `-1` was allowed to be used. >> >> I've also made two cleanup changes as part of this fix: >> >> 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should >> be properly `#ifdef`'ed. There is also some code that makes sense for ELF format >> files, but not for Mach-O format files so that code needs to be excluded on macOS. >> >> 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an >> `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code >> base so I'd like to fix it with this bug ID since I'm in related areas. >> >> This fix has been tested with Mach5 Tier[1-6]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8273967.cr1.patch Looks good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6193 From stuefe at openjdk.java.net Fri Nov 5 05:19:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 5 Nov 2021 05:19:15 GMT Subject: RFR: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 17:02:05 GMT, Mandy Chung wrote: >> `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. >> >> This patch removes the display of reflection targets from these commands as well as associated helper code and tests. >> >> I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. >> >> The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. >> >> Tests: GHAs, manually testing the commands. > > Looks good to me. Thanks for following this up. The new implementation does not spin any new class loader and so I don't think jcmd needs to extend its support for the new implementation using method handles. Thanks @mlchung, @coleenp and @dholmes-ora. ------------- PR: https://git.openjdk.java.net/jdk/pull/6257 From stuefe at openjdk.java.net Fri Nov 5 05:19:15 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 5 Nov 2021 05:19:15 GMT Subject: Integrated: JDK-8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 In-Reply-To: References: Message-ID: <7mVhoO4DH6O8bRsa1YBfnlRFAkY3UXeR1v_wPZzgsF0=.7d26c042-2d77-428a-bfb5-dd9b25e4aaa6@github.com> On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote: > `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out reflection invocation targets for delegating reflection class loaders. Post JEP 416 we don't use DelegatingClassLoaders anymore. > > This patch removes the display of reflection targets from these commands as well as associated helper code and tests. > > I don't have enough time atm to reimplement this feature using method handles. But at least we can remove the old code, and prepare the way for more code removal. > > The patch does not touch vmClasses, `reflect_ConstructorAccessor` and `reflect_MethodAccessor` are both still there. > > Tests: GHAs, manually testing the commands. This pull request has now been integrated. Changeset: 7281861e Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/7281861e0662e6c51507066a1f12673a236c7491 Stats: 368 lines in 8 files changed: 0 ins; 367 del; 1 mod 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6257 From qingfeng.yy at alibaba-inc.com Fri Nov 5 08:34:25 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Fri, 05 Nov 2021 16:34:25 +0800 Subject: =?UTF-8?B?UmU6IFtFeHRlcm5hbF0gOiBSZTogUkZDOiBFeHRlbmQgRENtZChEaWFnbm9zdGljLUNvbW1h?= =?UTF-8?B?bmQpIGZyYW1ld29yayB0byBzdXBwb3J0IEphdmEgbGV2ZWwgRENtZA==?= In-Reply-To: References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com>, Message-ID: Hi all, I had an offline discussion about this with Denghui, when I first time hear this idea, I felt it was useful. It allows users to do some stuff that requires a lot of effort in a simple way. I'm also tracking discussion on the mailing list, I've seen many folks come up with very constructive comments and questions/concerns. In order to make the follow-up discussion simple, I want to try to summarize and give some answers on behalf of myself. Each headline is a question/concern that folks are concerned about, followed by my personal opinion on it. I'd appreciate it if you can append any missing content. === What is it? It provides the ability for users to trigger predefined callbacks while the application is running. === May misuse? It is provided through jcmd, this ability should ideally be used for debugging/development/diagnosis purposes. It may be misused, but this is beyond our control, just as users can use signal handler to download App and play a song. === Maintainability? It expands current jcmd implementation rather than a significant modification, so maintainability should be ok IMHO. === Safety? Undeniably, it may raise some potential security issues. === Alternatives? Socket: It is inconvenient for users to simply do the same thing compared to this, we have to write a lot of boilerplate socket code. Signal: Not open to users, a limited number of signals, more likely to be misused. === Purpose? 1. I have a web application that can analyze Java heap dump. I hope to provide a simple way to report runtime app metrics, such as disk usage and online worker load, instead of writing a complete web page and providing an admin page to access it. This information can also be gathered on other monitoring platforms.2. Trigger the DEBUG functionality while running, output some debug logs Best regards. ------------------------------------------------------------------ From:Chris Plummer Send Time:2021 Nov. 4 (Thu.) 14:10 To:dong denghui ; serviceability-dev ; hotspot-dev Subject:Re: [External] : Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd Hi Denghui, Yes, there are other ways the same thing could be accomplished like sockets or signals, but all of this is outside of the purview of the JDK, and therefore we don't become responsible for its design, maintenance, and potential security concerns. EnableUserLevelDCmd doesn't really fix any of these concerns, because an app can just always launch with this flag enabled. It really should be reserved for launching a JVM for the specific purpose of gathering some extra diagnostic data, but there is no way to enforce that. Anyway, I'm not the gatekeeper on this. Just expressing some of my concerns. Others have done the same. I think we've seen a lack of enthusiasm in favor of doing this except from you. I would be good to see input from others that would like this feature in place. cheers, Chris On 11/1/21 8:09 PM, Denghui Dong wrote: Hi Chris, Thank you for the comments. Yes, we have no good way to restrict the user registration commands to only include diagnosis-related operations, but in my opinion, this does not seem to be a problem that must be solved perfectly. The following are my thoughts. This extension is an entry that triggers the operation that the user wants to perform (similar to the Signal Handler mechanism but with a name and parameters). Even without this extension, the user can have other ways to achieve the same goal. On the one hand, we could standardize the usage scenarios of the API on the document(Indeed, users can still write programs not in accordance with the specifications, for example, users can implement multiple calls to the same object's hachCode method to return different values or make an object alive again during finalize method executing). On the other hand, we can add some restrictions to help users make better use of this extension. e.g we can add a new VM option, such as EnableUserLevelDCmd, the application can only register customer commands when this option is enabled. Or from another perspective, can we allow users to do some non-diagnostic-related operations in custom commands? Best, Denghui ------------------------------------------------------------------ From:Chris Plummer Send Time:2021?11?2?(???) 03:35 To:???(??) ; serviceability-dev ; hotspot-dev Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd I have similar concerns to those others have expressed, so I'll try to add something new to the discussion and not just repeat. DCMDs have historically been very VM centric. That's not to say they aren't useful for debugging applications, but they do so by providing VM related info like stack traces, heap dumps, and class histograms. Also hotspot has been the gatekeeper for new DCMDs, meaning that new ones do not get added without going through the hotspot review process. Allowing any application or framework to add a DCMD changes this VM centric view in a way that concerns me. This approach allows a DCMD to pretty much do anything (java security not withstanding). App writers could even use them to provide a user facing interface. For example, if an app has some sort internal database, it could allow users to query it via a DCMD, and maybe even suggest that users write simple shell scripts that use jcmd to do these queries. Allowing this type of non-diagnostic usage seems like a path we don't want to go down, yet I don't see how it can be prevented once you allow applications to add DCMDs. Chris On 10/25/21 1:37 AM, Denghui Dong wrote: 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 lkorinth at openjdk.java.net Fri Nov 5 09:46:17 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 09:46:17 GMT Subject: Integrated: 8276173: Clean up and remove unneeded casts in HeapDumper In-Reply-To: <7UWZhgvlTjtIEiL6xV0hAVdm5elGVpn8DUliJ5Xvt90=.0f5ca378-5579-45ad-814b-61d0f9d83865@github.com> References: <7UWZhgvlTjtIEiL6xV0hAVdm5elGVpn8DUliJ5Xvt90=.0f5ca378-5579-45ad-814b-61d0f9d83865@github.com> Message-ID: On Tue, 2 Nov 2021 13:51:42 GMT, Leo Korinth wrote: > HeapDumper does a lot of unneeded casts. Some arguments should be const. Headers are not correctly sorted. Comment about identifier size on Windows and Solaris is not true. > > First I cleaned up casting in the "union casting", but then I decided it was better to create a temporary bit_cast that we can use until we get the proper one in c++20. This pull request has now been integrated. Changeset: 3c0faa73 Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 Stats: 53 lines in 1 file changed: 8 ins; 14 del; 31 mod 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/6211 From lkorinth at openjdk.java.net Fri Nov 5 09:46:16 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 09:46:16 GMT Subject: RFR: 8276173: Clean up and remove unneeded casts in HeapDumper [v2] In-Reply-To: References: <7UWZhgvlTjtIEiL6xV0hAVdm5elGVpn8DUliJ5Xvt90=.0f5ca378-5579-45ad-814b-61d0f9d83865@github.com> Message-ID: On Tue, 2 Nov 2021 19:25:40 GMT, Leo Korinth wrote: >> HeapDumper does a lot of unneeded casts. Some arguments should be const. Headers are not correctly sorted. Comment about identifier size on Windows and Solaris is not true. >> >> First I cleaned up casting in the "union casting", but then I decided it was better to create a temporary bit_cast that we can use until we get the proper one in c++20. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests Thanks Coleen and Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/6211 From shade at openjdk.java.net Fri Nov 5 10:13:08 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 5 Nov 2021 10:13:08 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 12:42:48 GMT, Aleksey Shipilev wrote: > 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` Anyone has opinions about this patch? :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From lkorinth at openjdk.java.net Fri Nov 5 11:38:27 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 11:38:27 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper Message-ID: Use override specifier in HeapDumper. It is safer. ------------- Commit messages: - 8276337: Use override specifier in HeapDumper Changes: https://git.openjdk.java.net/jdk/pull/6274/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6274&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276337 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6274/head:pull/6274 PR: https://git.openjdk.java.net/jdk/pull/6274 From ihse at openjdk.java.net Fri Nov 5 12:11:18 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 5 Nov 2021 12:11:18 GMT Subject: Integrated: 8276628: Use blessed modifier order in serviceability code In-Reply-To: References: Message-ID: <2SDPO7MFjKGYKDVlnVRdStd7XwlgsX3XA9PMfIGph5g=.8efd0769-4b5b-4014-b4ea-b6043f45b97f@github.com> On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. This pull request has now been integrated. Changeset: 7023b3f8 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b Stats: 284 lines in 89 files changed: 0 ins; 0 del; 284 mod 8276628: Use blessed modifier order in serviceability code Reviewed-by: dholmes, lmesnik, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From dholmes at openjdk.java.net Fri Nov 5 12:49:14 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Nov 2021 12:49:14 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 11:32:24 GMT, Leo Korinth wrote: > Use override specifier in HeapDumper. It is safer. In what way is it "safer" ?? What are you trying to guard against? ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From lkorinth at openjdk.java.net Fri Nov 5 13:09:10 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 13:09:10 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 12:45:56 GMT, David Holmes wrote: > In what way is it "safer" ?? What are you trying to guard against? If you use `override`, you can not forget to update a method signature if you change the method signature in the base class. You can also not by mistake change the method signature in this class without realizing you should change the base class. There is no downside of using `override` that I know of. ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From lkorinth at openjdk.java.net Fri Nov 5 13:09:10 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 13:09:10 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 11:32:24 GMT, Leo Korinth wrote: > Use override specifier in HeapDumper. It is safer. I have some new code in the pipe, and I want to use `override` in that code without changing unrelated code in heapDumper.cpp. Thus I first make this change so that my future change can keep the "style" of the file. ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From dcubed at openjdk.java.net Fri Nov 5 14:14:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 14:14:12 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: <-CAS0w-b0QThAGOMqni0ZYYcRyjEr2dcSP13fAy7__w=.b03d740c-22e2-47e8-a669-b3799e6478b6@github.com> References: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> <-CAS0w-b0QThAGOMqni0ZYYcRyjEr2dcSP13fAy7__w=.b03d740c-22e2-47e8-a669-b3799e6478b6@github.com> Message-ID: On Fri, 5 Nov 2021 05:16:28 GMT, Thomas Stuefe wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273967.cr1.patch > > Looks good! @tstuefe - Thanks for the re-review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From lkorinth at openjdk.java.net Fri Nov 5 14:14:43 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 14:14:43 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper [v2] In-Reply-To: References: Message-ID: > Use override specifier in HeapDumper. It is safer. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: restart failed github tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6274/files - new: https://git.openjdk.java.net/jdk/pull/6274/files/cf6ca4fd..dacd7355 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6274&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6274&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6274.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6274/head:pull/6274 PR: https://git.openjdk.java.net/jdk/pull/6274 From stuefe at openjdk.java.net Fri Nov 5 14:34:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 5 Nov 2021 14:34:11 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper [v2] In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 14:14:43 GMT, Leo Korinth wrote: >> Use override specifier in HeapDumper. It is safer. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests Hi Leo, seems fine. ..Thomas src/hotspot/share/services/heapDumper.cpp line 626: > 624: void deactivate() override { flush(); _backend.deactivate(); } > 625: // Get the backend pointer, used by parallel dump writer. > 626: CompressionBackend* backend_ptr() { return &_backend; } Unrelated, but could be a const method, no? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6274 From gziemski at openjdk.java.net Fri Nov 5 14:53:09 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 5 Nov 2021 14:53:09 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> References: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> Message-ID: On Thu, 4 Nov 2021 22:59:39 GMT, Daniel D. Daugherty wrote: >> macOS12 has changed the dladdr() function to accept "-1" as a valid address and >> we have functions that use dladdr() to convert DLL addresses into function or >> library names. We also have a gtest that verifies that "-1" is not a valid value to use >> as a symbol address. >> >> As you might imagine, existing code that uses `os::dll_address_to_function_name()` >> or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) >> if an `addr` parameter of `-1` was allowed to be used. >> >> I've also made two cleanup changes as part of this fix: >> >> 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should >> be properly `#ifdef`'ed. There is also some code that makes sense for ELF format >> files, but not for Mach-O format files so that code needs to be excluded on macOS. >> >> 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an >> `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code >> base so I'd like to fix it with this bug ID since I'm in related areas. >> >> This fix has been tested with Mach5 Tier[1-6]. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > 8273967.cr1.patch Marked as reviewed by gziemski (Committer). Thank you Dan for the fix! ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Fri Nov 5 15:00:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 15:00:12 GMT Subject: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2] In-Reply-To: References: <3p3sNenJDDg8kppLUdXaKMOQjKH9Zg0shxYadoSqLLQ=.1b4d377b-786c-4224-be24-cb2e2ad2685e@github.com> Message-ID: <5RTMLqlFwLfFW_eVOSqw5L2r8aoKXralWzs85fV7y_M=.549bd7e1-3ede-4763-b052-fa90166f77a2@github.com> On Fri, 5 Nov 2021 14:49:45 GMT, Gerard Ziemski wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273967.cr1.patch > > Thank you Dan for the fix! @gerard-ziemski - Thanks for the re-review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From stuefe at openjdk.java.net Fri Nov 5 15:04:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 5 Nov 2021 15:04:16 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 13:02:52 GMT, Leo Korinth wrote: > > In what way is it "safer" ?? What are you trying to guard against? > > If you use `override`, you can not forget to update a method signature if you change the method signature in the base class. You can also not by mistake change the method signature in this class without realizing you should change the base class. There is no downside of using `override` that I know of. In addition to that, its a helpful documentation for the code reader. ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From dcubed at openjdk.java.net Fri Nov 5 15:43:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 15:43:37 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v12] 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: 8249004.cr4.patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/86fcdfbe..91173506 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=10-11 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 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 Fri Nov 5 15:54:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 15:54:17 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: On Thu, 4 Nov 2021 19:33:33 GMT, Coleen Phillimore wrote: >> 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. > > Should the ThreadsListHandle protect JvmtiThreadState::first also? If state->next() needs it why doesn't the first entry need this? There's no atomic load on the _head field. The `ThreadsListHandle` protects `JavaThread` objects not `JvmtiThreadState` objects. `JvmtiThreadState::first()` returns the head of the global list of `JvmtiThreadState` objects for the system. Each `JvmtiThreadState` object contains a `JavaThread*` and we have to protect use of the `JavaThread*` which can happen in the `recompute_thread_enabled(state)` call below. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 15:54:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 15:54:17 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Thu, 4 Nov 2021 21:44:45 GMT, Coleen Phillimore wrote: >> I'm really tempted to go ahead and change it to always set >> current thread when it is declared and then clean things up a bit. > > Yes, ^ that might make the logic easier to follow. I can't figure out what checkTLSOnly means. Could it be refactored into a different function like check_TLS() and then call it in the place where you pass true instead of is_JavaThread_protected? Does checkTLSOnly skip a lot of these checks? I've changed `is_JavaThread_protected()` to materialize current_thread when it is declared to simplify the code paths. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 15:54:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 15:54:17 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Fri, 5 Nov 2021 15:15:14 GMT, Daniel D. Daugherty wrote: >> Yes, ^ that might make the logic easier to follow. I can't figure out what checkTLSOnly means. Could it be refactored into a different function like check_TLS() and then call it in the place where you pass true instead of is_JavaThread_protected? Does checkTLSOnly skip a lot of these checks? > > I've changed `is_JavaThread_protected()` to materialize current_thread when it is declared > to simplify the code paths. > I can't figure out what checkTLSOnly means. See the function's header comment: // ... If checkTLHOnly is true (default is false), then we only check // if the target JavaThread is protected by a ThreadsList (if any) associated // with the calling Thread. > Could it be refactored into a different function like check_TLS() and then > call it in the place where you pass true instead of is_JavaThread_protected? I had a copy of this logic in a separate function and @dholmes-ora suggested that I add the `checkTLHOnly` parameter to this function and get rid of the separate copy so I've been there and done that. I could *move* the logic into a separate function and then call that new function from here and from the other call sites that pass `true`, but then I'd have to materialize current_thread in that new function and then on this code path we would be materializing current_thread twice. I don't want to do that. > Does checkTLSOnly skip a lot of these checks? Please read the header comment to see what `checkTLHOnly` does. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 16:06:12 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 16:06:12 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Thu, 4 Nov 2021 21:45:16 GMT, Coleen Phillimore wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> 8249004.cr2.patch > > Sorry for such a long delay looking at this. I had a couple questions and a suggestion. @coleenp - Thanks for the re-review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Fri Nov 5 16:06:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Nov 2021 16:06:13 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 Mon, 1 Nov 2021 15:59:58 GMT, Daniel D. Daugherty wrote: >> Update: I've added comments to WB_HandshakeReadMonitors() and >> WB_HandshakeWalkStack() to clarify their expectations. > > Update again: I took a closer look at `WB_AsyncHandshakeWalkStack()`, > `WB_HandshakeReadMonitors()` and `WB_HandshakeWalkStack()` and > I realized that those functions were not properly converting a `jobject` into > a protected JavaThread*. I've updated them to call the proper conversion > function and I've changed this code to `guarantee()` that the target is not > `nullptr`. Great. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From lkorinth at openjdk.java.net Fri Nov 5 16:30:10 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 5 Nov 2021 16:30:10 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper [v2] In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 14:30:33 GMT, Thomas Stuefe wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> restart failed github tests > > src/hotspot/share/services/heapDumper.cpp line 626: > >> 624: void deactivate() override { flush(); _backend.deactivate(); } >> 625: // Get the backend pointer, used by parallel dump writer. >> 626: CompressionBackend* backend_ptr() { return &_backend; } > > Unrelated, but could be a const method, no? Not easily I think, if I make the method const, I would have to return a const pointer, and then I need to do const operations on the backend etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From coleenp at openjdk.java.net Fri Nov 5 16:51:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Nov 2021 16:51:21 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v12] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Fri, 5 Nov 2021 15:43:37 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.cr4.patch Thanks for the offline comments. I still think refactoring is_JavaThread_protected would be a lot nicer but that's my opinion and you don't have to change it. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Fri Nov 5 16:51:21 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Nov 2021 16:51:21 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: On Fri, 5 Nov 2021 15:38:27 GMT, Daniel D. Daugherty wrote: >> Should the ThreadsListHandle protect JvmtiThreadState::first also? If state->next() needs it why doesn't the first entry need this? There's no atomic load on the _head field. > > The `ThreadsListHandle` protects `JavaThread` objects not `JvmtiThreadState` objects. > `JvmtiThreadState::first()` returns the head of the global list of `JvmtiThreadState` > objects for the system. Each `JvmtiThreadState` object contains a `JavaThread*` and > we have to protect use of the `JavaThread*` which can happen in the > `recompute_thread_enabled(state)` call below. JvmtiThreadState objects point to JavaThread and vice versa, so I still don't see why you don't protect the first element. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 17:01:13 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 17:01:13 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: <1V8JyD2LBGYu7Zs8Ux0aGrprOFsayNZi6OqpvAUDvuc=.ab1bc129-84b7-483e-8473-56f099e0b075@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 and @sspitsyn - I still need a re-review from you guys. @robehn - A re-review from you would be good, but I think I cleanly addressed your last comments... ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 17:08:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 17:08:17 GMT Subject: Integrated: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 15:32:54 GMT, Daniel D. Daugherty wrote: > macOS12 has changed the dladdr() function to accept "-1" as a valid address and > we have functions that use dladdr() to convert DLL addresses into function or > library names. We also have a gtest that verifies that "-1" is not a valid value to use > as a symbol address. > > As you might imagine, existing code that uses `os::dll_address_to_function_name()` > or `os::dll_address_to_library_name()` can get quite confused (and sometimes crash) > if an `addr` parameter of `-1` was allowed to be used. > > I've also made two cleanup changes as part of this fix: > > 1) In `src/hotspot/os/bsd/os_bsd.cpp` there is some macOS specific code that should > be properly `#ifdef`'ed. There is also some code that makes sense for ELF format > files, but not for Mach-O format files so that code needs to be excluded on macOS. > > 2) In `src/hotspot/share/runtime/os.cpp` I noticed a simple typo in a comment on an > `#endif` that I fixed. That typo does not appear anywhere else in the HotSpot code > base so I'd like to fix it with this bug ID since I'm in related areas. > > This fix has been tested with Mach5 Tier[1-6]. This pull request has now been integrated. Changeset: 92d21763 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/92d2176362954a7093894057748056610eeafe4b Stats: 46 lines in 4 files changed: 34 ins; 8 del; 4 mod 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Reviewed-by: stuefe, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/6193 From dcubed at openjdk.java.net Fri Nov 5 20:49:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 20:49:42 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: On Fri, 5 Nov 2021 16:43:04 GMT, Coleen Phillimore wrote: >> The `ThreadsListHandle` protects `JavaThread` objects not `JvmtiThreadState` objects. >> `JvmtiThreadState::first()` returns the head of the global list of `JvmtiThreadState` >> objects for the system. Each `JvmtiThreadState` object contains a `JavaThread*` and >> we have to protect use of the `JavaThread*` which can happen in the >> `recompute_thread_enabled(state)` call below. > > JvmtiThreadState objects point to JavaThread and vice versa, so I still don't see why you don't protect the first element. I've written up a rather long analysis about how the use of `JvmtiThreadState_lock` in `JvmtiEventControllerPrivate::recompute_enabled()` means that we can safely traverse the JvmtiThreadState list returned by `JvmtiThreadState::first()` without racing with an exiting JavaThread. I've sent it to you via direct email. I could amend the comment above the ThreadsListHandle like this: // If we have a JvmtiThreadState, then we've reached the point where // threads can exist so create a ThreadsListHandle to protect them. // The held JvmtiThreadState_lock prevents exiting JavaThreads from // being removed from the JvmtiThreadState list we're about to walk // so this ThreadsListHandle exists just to satisfy the lower level sanity // checks that the target JavaThreads are protected. ThreadsListHandle tlh; ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 21:45:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 21:45:40 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v12] In-Reply-To: References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Fri, 5 Nov 2021 15:43:37 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.cr4.patch > JvmtiThreadState objects point to JavaThread and vice versa, so I still don't see why you don't protect the first element. I've written up a rather long analysis about how the use of JvmtiThreadState_lock in JvmtiEventControllerPrivate::recompute_enabled() means that we can safely traverse the JvmtiThreadState list returned by JvmtiThreadState::first() without racing with an exiting JavaThread. I've sent it to you via direct email. I could amend the comment above the ThreadsListHandle like this: // If we have a JvmtiThreadState, then we've reached the point where // threads can exist so create a ThreadsListHandle to protect them. // The held JvmtiThreadState_lock prevents exiting JavaThreads from // being removed from the JvmtiThreadState list we're about to walk // so this ThreadsListHandle exists just to satisfy the lower level sanity // checks that the target JavaThreads are protected. ThreadsListHandle tlh; ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From coleenp at openjdk.java.net Fri Nov 5 21:56:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 5 Nov 2021 21:56:42 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: On Fri, 5 Nov 2021 20:46:21 GMT, Daniel D. Daugherty wrote: >> JvmtiThreadState objects point to JavaThread and vice versa, so I still don't see why you don't protect the first element. > > I've written up a rather long analysis about how the use of `JvmtiThreadState_lock` > in `JvmtiEventControllerPrivate::recompute_enabled()` means that we can safely > traverse the JvmtiThreadState list returned by `JvmtiThreadState::first()` without > racing with an exiting JavaThread. I've sent it to you via direct email. > > I could amend the comment above the ThreadsListHandle like this: > > // If we have a JvmtiThreadState, then we've reached the point where > // threads can exist so create a ThreadsListHandle to protect them. > // The held JvmtiThreadState_lock prevents exiting JavaThreads from > // being removed from the JvmtiThreadState list we're about to walk > // so this ThreadsListHandle exists just to satisfy the lower level sanity > // checks that the target JavaThreads are protected. > ThreadsListHandle tlh; Yes, this comment is good and it does explain why it's safe and why the TLH is there. Thanks for doing the deep dive and explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dholmes at openjdk.java.net Fri Nov 5 22:52:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 5 Nov 2021 22:52:39 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper [v2] In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 14:14:43 GMT, Leo Korinth wrote: >> Use override specifier in HeapDumper. It is safer. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests Marked as reviewed by dholmes (Reviewer). The only "downside" to using `override` is that if you use it on one method then you must use it on all applicable methods in a class, so it can tend to have a viral affect in terms of the scope of changes needed just to add the case(s) you're really interested in. My experience with `override` in Java is a negative one as I often fail to add the annotation and then get chastised by the compiler for my oversight. It might be useful when writing larger libraries with class hierarchies but I find it a hinderence when writing simple code like tests. For C++ I find the placement of override awkward and less visible than virtual. ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From dcubed at openjdk.java.net Fri Nov 5 23:42:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 23:42:07 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v13] In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@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: coleenp CR - clarify need for ThreadsListHandle in JvmtiEventControllerPrivate::recompute_enabled(). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4677/files - new: https://git.openjdk.java.net/jdk/pull/4677/files/91173506..fe28cbe9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=11-12 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 Fri Nov 5 23:47:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 23:47:41 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v13] In-Reply-To: <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> Message-ID: On Fri, 5 Nov 2021 23:42:07 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: > > coleenp CR - clarify need for ThreadsListHandle in JvmtiEventControllerPrivate::recompute_enabled(). Updated comment has been pushed to this PR. For some reason, the comments that @coleenp and I are posting in the "Files changed" view are not showing up here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Fri Nov 5 23:47:41 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 5 Nov 2021 23:47:41 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: On Fri, 5 Nov 2021 21:54:01 GMT, Coleen Phillimore wrote: >> I've written up a rather long analysis about how the use of `JvmtiThreadState_lock` >> in `JvmtiEventControllerPrivate::recompute_enabled()` means that we can safely >> traverse the JvmtiThreadState list returned by `JvmtiThreadState::first()` without >> racing with an exiting JavaThread. I've sent it to you via direct email. >> >> I could amend the comment above the ThreadsListHandle like this: >> >> // If we have a JvmtiThreadState, then we've reached the point where >> // threads can exist so create a ThreadsListHandle to protect them. >> // The held JvmtiThreadState_lock prevents exiting JavaThreads from >> // being removed from the JvmtiThreadState list we're about to walk >> // so this ThreadsListHandle exists just to satisfy the lower level sanity >> // checks that the target JavaThreads are protected. >> ThreadsListHandle tlh; > > Yes, this comment is good and it does explain why it's safe and why the TLH is there. Thanks for doing the deep dive and explanation. Updated comment has been pushed to this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From sspitsyn at openjdk.java.net Sat Nov 6 12:19:44 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 6 Nov 2021 12:19:44 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: References: Message-ID: <8m9CsDb7qxf9zb8FHzR-IMkVp-UQYCmqnWFzS6dPGaM=.0e4b9719-3b95-4ac1-a3e0-64bd009f96af@github.com> On Thu, 4 Nov 2021 02:15:45 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). > > Ioi Lam 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 'master' into 8275185-jvmstat-LocalVmManager-cleanup-and-remove-dead-code > - @kevinjwalls and @plummercj review - (1) restore PerfDataFile.userDirNamePattern, etc. (2) Fixed comments > - 8275185: Remove dead code and clean up jvmstat LocalVmManager Hi Ioi, Sorry for being late here. Just to complete this... Thank you for your answers! I'm okay with them. ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From iklam at openjdk.java.net Sat Nov 6 16:49:40 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 6 Nov 2021 16:49:40 GMT Subject: RFR: 8275185: Remove dead code and clean up jvmstat LocalVmManager [v2] In-Reply-To: <8m9CsDb7qxf9zb8FHzR-IMkVp-UQYCmqnWFzS6dPGaM=.0e4b9719-3b95-4ac1-a3e0-64bd009f96af@github.com> References: <8m9CsDb7qxf9zb8FHzR-IMkVp-UQYCmqnWFzS6dPGaM=.0e4b9719-3b95-4ac1-a3e0-64bd009f96af@github.com> Message-ID: On Sat, 6 Nov 2021 12:16:10 GMT, Serguei Spitsyn wrote: > Hi Ioi, > Sorry for being late here. > Just to complete this... > Thank you for your answers! I'm okay with them. Thanks Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/5923 From duke at openjdk.java.net Sun Nov 7 19:13:34 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Sun, 7 Nov 2021 19:13:34 GMT Subject: RFR: 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat [v2] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 07:32:47 GMT, Andrey Turbanov wrote: >> There are few places in code where manual `for` loop is used with Iterator to iterate over Collection or Array. >> 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 >> 4. [JDK-8274318](https://bugs.openjdk.java.net/browse/JDK-8274318) java.management > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat > update copyright Can someone sponsor the changes please? ------------- PR: https://git.openjdk.java.net/jdk/pull/5580 From duke at openjdk.java.net Sun Nov 7 19:21:54 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Sun, 7 Nov 2021 19:21:54 GMT Subject: RFR: 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat [v3] In-Reply-To: References: Message-ID: > There are few places in code where manual `for` loop is used with Iterator to iterate over Collection or Array. > 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 > 4. [JDK-8274318](https://bugs.openjdk.java.net/browse/JDK-8274318) java.management Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'origin/master' into cleanup_use_enhanced-for_in_jdk.internal.jvmstat # Conflicts: # src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java - 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat update copyright - [PATCH] Use enhanced-for instead of plain for in jdk.internal.jvmstat ------------- Changes: https://git.openjdk.java.net/jdk/pull/5580/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5580&range=02 Stats: 49 lines in 7 files changed: 3 ins; 11 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/5580.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5580/head:pull/5580 PR: https://git.openjdk.java.net/jdk/pull/5580 From dholmes at openjdk.java.net Sun Nov 7 23:59:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 7 Nov 2021 23:59:37 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v13] In-Reply-To: <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> Message-ID: On Fri, 5 Nov 2021 23:42:07 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: > > coleenp CR - clarify need for ThreadsListHandle in JvmtiEventControllerPrivate::recompute_enabled(). Thanks Dan - updates look good. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4677 From ddong at openjdk.java.net Mon Nov 8 01:26:37 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 8 Nov 2021 01:26:37 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: On Sun, 31 Oct 2021 22:56:44 GMT, Denghui Dong wrote: >> 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 Gentle ping? This problem seems to have existed for a long time. I think it's because there are few users, so it's not reported As far as I know, a BCC's tool relies on this probe. https://github.com/iovisor/bcc/blob/master/tools/lib/uobjnew.py#L110 ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From dholmes at openjdk.java.net Mon Nov 8 01:54:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 8 Nov 2021 01:54:34 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: On Sun, 31 Oct 2021 22:56:44 GMT, Denghui Dong wrote: >> 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 To me something like `dtrace_object_alloc_base` should not be called directly (like a foo_impl function) but only as the implementation of the real API entry points. If that isn't the case here then lets drop the "base" part and just have a set of overloaded `dtrace_object_alloc` functions. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6181 From ddong at openjdk.java.net Mon Nov 8 02:42:58 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 8 Nov 2021 02:42:58 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] 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: update according to comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6181/files - new: https://git.openjdk.java.net/jdk/pull/6181/files/8d597ebc..0527097e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6181&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6181&range=01-02 Stats: 17 lines in 13 files changed: 0 ins; 0 del; 17 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 ddong at openjdk.java.net Mon Nov 8 02:42:58 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 8 Nov 2021 02:42:58 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: On Mon, 8 Nov 2021 01:51:30 GMT, David Holmes wrote: > To me something like `dtrace_object_alloc_base` should not be called directly (like a foo_impl function) but only as the implementation of the real API entry points. If that isn't the case here then lets drop the "base" part and just have a set of overloaded `dtrace_object_alloc` functions. > > Thanks, David Changed. Thanks, Denghui ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From asarkar at openjdk.java.net Mon Nov 8 04:20:39 2021 From: asarkar at openjdk.java.net (Anirvan Sarkar) Date: Mon, 8 Nov 2021 04:20:39 GMT Subject: RFR: 8276628: Use blessed modifier order in serviceability code [v2] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie wrote: >> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update copyright year > (And we _really_ ought to wrangle free some resources to write tooling for us to do all the copyright dances...) OpenJFX team seems to have a copyright update script[1]. Maybe @kevinrushforth can tell if it can be retrofitted and used by OpenJDK project. [1] : https://bugs.openjdk.java.net/browse/JDK-8214793?focusedCommentId=14233661&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14233661 ------------- PR: https://git.openjdk.java.net/jdk/pull/6249 From dholmes at openjdk.java.net Mon Nov 8 05:23:38 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 8 Nov 2021 05:23:38 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] In-Reply-To: References: Message-ID: <2selTWcClSy4aHruUOuUlErZUVny8-VgrladwcRJVm4=.830e17bf-d507-452e-a37f-f6c819666955@github.com> On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote: >> 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: > > update according to comments Did your change actually work? I just realized that you can't use this: ```__ call(RuntimeAddress(CAST_FROM_FN_PTR(address, static_cast(SharedRuntime::dtrace_object_alloc))));``` because it has no idea what overload of `dtrace_object_alloc` needs to be invoked. David ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From dholmes at openjdk.java.net Mon Nov 8 05:36:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 8 Nov 2021 05:36:33 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote: >> 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: > > update according to comments Sorry ignore that. I see that is what the static_cast is intended to do. I got confused by the need to change the additional call-sites that already used `dtrace_object_alloc`, because they were the ones previously calling the two-arg function but only passing one arg! ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From dholmes at openjdk.java.net Mon Nov 8 05:52:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 8 Nov 2021 05:52:34 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote: >> 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: > > update according to comments I understand now what you meant by the additional overload complicating the fix - I hadn't appreciated that may have been the reason for using different names for the functions originally. I'm still unclear why the lack of the size argument did not cause problems? I guess whatever random value was next on the stack got read as the size, but reading it caused no harm it was just incorrect. These changes look good to me now. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6181 From rehn at openjdk.java.net Mon Nov 8 08:26:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 8 Nov 2021 08:26:43 GMT Subject: RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v13] In-Reply-To: <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> <6T6e2H-ukrqR8ZemUFBES05S6tQx-ZuoWG0Uw12uNs4=.415abb3b-bf42-402c-8d4c-b944186320b2@github.com> Message-ID: <-HLPdSRcefxVpqc6TE_0_L-BgkxV5ev9itsVV5UqPrs=.4dfae20e-b749-411b-9669-cc4351004ad0@github.com> On Fri, 5 Nov 2021 23:42:07 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: > > coleenp CR - clarify need for ThreadsListHandle in JvmtiEventControllerPrivate::recompute_enabled(). Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From ddong at openjdk.java.net Mon Nov 8 12:11:33 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 8 Nov 2021 12:11:33 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote: >> 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: > > update according to comments Thank you, David. Could I have another review? ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From coleenp at openjdk.java.net Mon Nov 8 13:48:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 8 Nov 2021 13:48:42 GMT Subject: RFR: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) [v3] In-Reply-To: References: Message-ID: <5ddSIvC7u6q93eA32fdwCpNuOKpfE0oOpI7qcL1yZ9I=.c2a2077d-9b82-4330-a5c9-2a893996d374@github.com> On Mon, 8 Nov 2021 02:42:58 GMT, Denghui Dong wrote: >> 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: > > update according to comments These casts are hard to look at but it seems fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6181 From ddong at openjdk.java.net Mon Nov 8 14:34:40 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Mon, 8 Nov 2021 14:34:40 GMT Subject: Integrated: 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) In-Reply-To: References: Message-ID: On Sun, 31 Oct 2021 15:08:11 GMT, Denghui Dong wrote: > 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 This pull request has now been integrated. Changeset: c815c5cb Author: Denghui Dong URL: https://git.openjdk.java.net/jdk/commit/c815c5cbbb0b6a2aebd0a38cb930c74bd665d082 Stats: 22 lines in 13 files changed: 6 ins; 0 del; 16 mod 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/6181 From dcubed at openjdk.java.net Mon Nov 8 14:48:46 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 8 Nov 2021 14:48:46 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: 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 and @robehn - Thanks for the re-reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From dcubed at openjdk.java.net Mon Nov 8 14:48:46 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 8 Nov 2021 14:48:46 GMT Subject: Integrated: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com> Message-ID: On Sat, 3 Jul 2021 14:15:54 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. This pull request has now been integrated. Changeset: ea23e733 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/ea23e7333e03abb4aca3e9f3854bab418a4b70e2 Stats: 121 lines in 7 files changed: 52 ins; 6 del; 63 mod 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/4677 From duke at openjdk.java.net Tue Nov 9 17:01:43 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 9 Nov 2021 17:01:43 GMT Subject: Integrated: 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 08:15:13 GMT, Andrey Turbanov wrote: > There are few places in code where manual `for` loop is used with Iterator to iterate over Collection or Array. > 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 > 4. [JDK-8274318](https://bugs.openjdk.java.net/browse/JDK-8274318) java.management This pull request has now been integrated. Changeset: 93692ea0 Author: Andrey Turbanov Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/93692ea0a9bc437309b808f511c771a79dcdfb9a Stats: 49 lines in 7 files changed: 3 ins; 11 del; 35 mod 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat Reviewed-by: cjplummer, amenkov, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5580 From lkorinth at openjdk.java.net Tue Nov 9 17:53:40 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 9 Nov 2021 17:53:40 GMT Subject: RFR: 8276337: Use override specifier in HeapDumper [v2] In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 14:14:43 GMT, Leo Korinth wrote: >> Use override specifier in HeapDumper. It is safer. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > restart failed github tests Thanks Thomas and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From lkorinth at openjdk.java.net Tue Nov 9 17:53:40 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 9 Nov 2021 17:53:40 GMT Subject: Integrated: 8276337: Use override specifier in HeapDumper In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 11:32:24 GMT, Leo Korinth wrote: > Use override specifier in HeapDumper. It is safer. This pull request has now been integrated. Changeset: daf77ebf Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/daf77ebfc4ca6d537ef55acbd62b908b5575ad08 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8276337: Use override specifier in HeapDumper Reviewed-by: stuefe, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6274 From chris.plummer at oracle.com Tue Nov 9 22:07:51 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 9 Nov 2021 14:07:51 -0800 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: <1b7ec152-d8ae-8b3b-8e4e-dc6eca2db1f4@oracle.com> On 10/14/21 12:38 AM, David Holmes wrote: > 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 Just reviewing some previous emails and noticed this one since I recently looked into the JMX support. JMX supports a rather generic concept of executing diagnostics commands (there is no actual reference to "dcmds"). See com.sun.management.DiagnosticCommandMBean and its superinterface javax.management.DynamicMBean: https://docs.oracle.com/en/java/javase/15/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html https://docs.oracle.com/en/java/javase/15/docs/api/java.management/javax/management/DynamicMBean.html DynamicMBean provides the invoke() interface, which when used on a DiagnosticCommandMBean will invoke the specified diagnostic command. It says nothing about how diagnostic commands are implemented or registered with the jvm. That I assume would be JVM implementation dependent. > 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 to "add a way to register a Java diagnostic command", but the new API will not involve DiagnosticCommandMBean in any way. The new API will interface with the existing hotspot native support for dcmds to allow dcmds to be implemented by and registered from java. In any case, I think having an API that allows you to invoke a diagnostic command from java is very different in scope from an API that allows you to implement one in java, so I'm not so sure this JMX precedence serves us much purpose here. Chris > >> Denghui >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/5938 >> From ioi.lam at oracle.com Tue Nov 9 22:54:37 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 9 Nov 2021 14:54:37 -0800 Subject: RFR: 8275259: Add support for Java level DCmd In-Reply-To: <1b7ec152-d8ae-8b3b-8e4e-dc6eca2db1f4@oracle.com> References: <48CHRA6hPJvj0wmgRjRKbV0b9WSv71sVk3NafMIdHi4=.a70075a9-68f7-4df7-bcd6-7de6de7cb259@github.com> <29edfa90-04a3-c8aa-8ac6-45c4a05eae76@oracle.com> <1b7ec152-d8ae-8b3b-8e4e-dc6eca2db1f4@oracle.com> Message-ID: <50d81def-1fb9-263a-f36c-82bfc7d6225e@oracle.com> On 11/9/21 2:07 PM, Chris Plummer wrote: > On 10/14/21 12:38 AM, David Holmes wrote: >> 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 > > Just reviewing some previous emails and noticed this one since I > recently looked into the JMX support. JMX supports a rather generic > concept of executing diagnostics commands (there is no actual > reference to "dcmds"). See com.sun.management.DiagnosticCommandMBean > and its superinterface javax.management.DynamicMBean: > > https://docs.oracle.com/en/java/javase/15/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html > > https://docs.oracle.com/en/java/javase/15/docs/api/java.management/javax/management/DynamicMBean.html > > > DynamicMBean provides the invoke() interface, which when used on a > DiagnosticCommandMBean will invoke the specified diagnostic command. > It says nothing about how diagnostic commands are implemented or > registered with the jvm. That I assume would be JVM implementation > dependent. > >> 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 to "add a way to register a Java diagnostic command", but the new > API will not involve DiagnosticCommandMBean in any way. The new API > will interface with the existing hotspot native support for dcmds to > allow dcmds to be implemented by and registered from java. > > In any case, I think having an API that allows you to invoke a > diagnostic command from java is very different in scope from an API > that allows you to implement one in java, so I'm not so sure this JMX > precedence serves us much purpose here. > Is there anything in the proposal that cannot be done by JMX? If the app wants to provide a hook to expose some of its internals to be monitored/controlled by an external tool, maybe it can just implement a new MBean? Granted, it's bit more tedious to connect to JMX than using "jcmd". However, much of that is for security. If we allow an app to implement new jcmd handlers using Java code, we have to think about the whole security model again. Are we reinventing the wheel here? Thanks - Ioi From sspitsyn at openjdk.java.net Wed Nov 10 01:28:43 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 01:28:43 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. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2189: > 2187: > 2188: /* > 2189: * trackAppResume() (indirectly) aquires handlerLock. For proper lock I'd suggest to get rid of '()' brackets in this comment line, so it will be: `* trackAppResume indirectly aquires handlerLock. For proper lock` ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From sspitsyn at openjdk.java.net Wed Nov 10 01:32:44 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 01:32:44 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. Hi Richard, The fix looks okay to me. I've inlined one minor suggestion. Thanks, Serguei src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2194: > 2192: debugMonitorExit(threadLock); > 2193: eventHandler_lock(); > 2194: debugMonitorEnter(threadLock); The lines 2192-2194 look like a hack to me. But I see you have filed an enhancement to fix this. I'm okay to address it later. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5849 From dholmes at openjdk.java.net Wed Nov 10 01:42:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 10 Nov 2021 01:42:47 GMT Subject: RFR: 8276265: jcmd man page is outdated Message-ID: It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html Summary of changes: New Commands: - Compiler.perfmap - System.trim_native_heap - VM.cds - VM.classloaders - VM.events - VM.metaspace Missing flags: - GC.class_histogram -parallel - GC.heap_dump - gz and overwrite options - Thread.print -e There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. Thanks, David ------------- Commit messages: - Removed temporary addition of html version. - Temporary commit of html version - 8276265: jcmd man page is outdated Changes: https://git.openjdk.java.net/jdk/pull/6271/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6271&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276265 Stats: 153 lines in 1 file changed: 146 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6271.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6271/head:pull/6271 PR: https://git.openjdk.java.net/jdk/pull/6271 From ddong at openjdk.java.net Wed Nov 10 01:59:39 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 10 Nov 2021 01:59:39 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: >> (RFC: https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-October/039796.html) >> >> 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 Thanks for the commands, the following is my thought. Compared with the user's own implementation of a DiagnosticCommandMBean, the main benefits of this extension are: Users can directly use `jcmd` to invoke (better user experience, of course, users can also invoke through a jmx client like jconsole), and use `jcmd pid help` to list all VM commands and user-defined commands. And all parameters or options are pre-parsed, making the implementation of the command simpler and focusing on their own logic. I am not an expert in the security field, but I feel that implementing a DiagnosticCommandMBean by the users does not seem to be more secure than the method in the proposal. I mean the users can still do whatever they want. Just like Chris said, it seems that not many people are interested in this proposal. I plan to close this PR first. If there are any others who want this in place, we can continue to discuss it in the RFC thread of this proposal. Denghui, Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From ddong at openjdk.java.net Wed Nov 10 02:25:42 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Wed, 10 Nov 2021 02:25:42 GMT Subject: Withdrawn: 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: > (RFC: https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-October/039796.html) > > 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5938 From chris.plummer at oracle.com Wed Nov 10 05:50:38 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 9 Nov 2021 21:50:38 -0800 Subject: [External] : Re: RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd In-Reply-To: References: <7f2df6ad-7d73-46ac-a23e-959fd6b4d4af.denghui.ddh@alibaba-inc.com> <6581e9e4-851a-c562-37af-915ff3fdc492@oracle.com> <8a5c6087-a131-4ddd-9195-0f1e51705351.denghui.ddh@alibaba-inc.com> Message-ID: <0d05daaa-82cb-1537-5292-03d8e1d1d625@oracle.com> Hi Denghui, Following up here with something that was discussed in the other email thread, Ioi asked if an MBean could be used to provide similar app diagnostics. It seems it can be. Erik also mentioned to me that the REST API can be used for something like this. The example he gave is a query something like the following: ?? curl http://localhost:8080?command=foo?param1=bar Also it has been pointed out that sockets could be used. I know a jcmd might be easier to use/access than any of these other 3 approaches, but we have to question if it is worth adding given all the concerns that have been pointed so far. thanks, Chris On 11/5/21 1:34 AM, Yi Yang wrote: > Hi all, > > I had an offline discussion about this with Denghui, when I first time > hear this idea, I felt it was useful. It allows users to do some stuff > that requires a lot of effort in a simple way. I'm also tracking > discussion on the mailing list, I've seen many folks come up with very > constructive comments and questions/concerns. In order to make the > follow-up discussion simple, I want to try to summarize and give some > answers on behalf of myself. Each headline is a question/concern that > folks are concerned about, followed by my personal opinion on it. I'd > appreciate it if you can append any missing content. > > === What is it? > It provides the ability for users to trigger predefined callbacks > while the application is running. > > === May misuse? > It is provided through jcmd, this ability should ideally be used for > debugging/development/diagnosis purposes. It may be misused, but this > is beyond our control, just as users can use signal handler to > download App and play a song. > > === Maintainability? > It expands current jcmd implementation rather than a significant > modification, so maintainability should be ok IMHO. > > === Safety? > Undeniably, it may raise some potential security issues. > > === Alternatives? > Socket: It is inconvenient for users to simply do the same thing > compared to this, we have to write a lot of boilerplate socket code. > Signal: Not open to users,? a limited number of signals, more likely > to be misused. > > === Purpose? > 1. I have a web application that can analyze Java heap dump. I hope to > provide a simple way to report runtime app metrics, such as disk usage > and online worker load, instead of writing a complete web page and > providing an admin page to access it. This information can also be > gathered on other monitoring platforms. > 2. Trigger the DEBUG functionality while running, output some debug logs > > Best regards. > > ------------------------------------------------------------------ > From:Chris Plummer > Send Time:2021 Nov. 4 (Thu.) 14:10 > To:dong denghui ; serviceability-dev > ; hotspot-dev > > Subject:Re: [External] : Re: RFC: Extend DCmd(Diagnostic-Command) > framework to support Java level DCmd > > Hi Denghui, > > Yes, there are other ways the same thing could be accomplished > like sockets or signals, but all of this is outside of the purview > of the JDK, and therefore we don't become responsible for its > design, maintenance, and potential security concerns. > EnableUserLevelDCmd doesn't really fix any of these concerns, > because an app can just always launch with this flag enabled. It > really should be reserved for launching a JVM for the specific > purpose of gathering some extra diagnostic data, but there is no > way to enforce that. > > Anyway, I'm not the gatekeeper on this. Just expressing some of my > concerns. Others have done the same. I think we've seen a lack of > enthusiasm in favor of doing this except from you. I would be good > to see input from others that would like this feature in place. > > cheers, > > Chris > > On 11/1/21 8:09 PM, Denghui Dong wrote: > Hi?Chris, > > Thank?you?for?the?comments. > > Yes,?we?have?no?good?way?to?restrict?the?user?registration?commands?to?only?include?diagnosis-related?operations,?but?in?my?opinion,?this?does?not?seem?to?be?a?problem?that?must?be?solved?perfectly. > > The?following?are?my?thoughts. > > This?extension?is?an?entry?that?triggers?the?operation?that?the?user?wants?to?perform?(similar?to?the?Signal?Handler?mechanism?but?with?a?name?and?parameters).?Even?without?this?extension,?the?user?can?have?other?ways?to?achieve?the?same?goal. > > On?the?one?hand,?we?could?standardize?the?usage?scenarios?of?the?API?on?the?document(Indeed,?users?can?still?write?programs?not?in?accordance?with?the?specifications,?for?example,?users?can?implement?multiple?calls?to?the?same?object's?hachCode?method?to?return?different?values?or?make?an?object?alive?again?during?finalize?method?executing). > > On?the?other?hand,?we?can?add?some?restrictions?to?help?users?make?better?use?of?this?extension. > e.g?we?can?add?a?new?VM?option,?such?as?EnableUserLevelDCmd,?the?application?can?only?register?customer?commands?when?this?option?is?enabled. > > Or?from?another?perspective,?can?we?allow?users?to?do?some?non-diagnostic-related?operations?in?custom?commands? > > Best, > Denghui > ------------------------------------------------------------------ > From:Chris Plummer > Send Time:2021?11?2?(???) 03:35 > To:???(??) ; serviceability-dev > ; hotspot-dev > > Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to > support Java level DCmd > > I have similar concerns to those others have expressed, so I'll > try to add something new to the discussion and not just repeat. > > DCMDs have historically been very VM centric. That's not to say > they aren't useful for debugging applications, but they do so by > providing VM related info like stack traces, heap dumps, and class > histograms. Also hotspot has been the gatekeeper for new DCMDs, > meaning that new ones do not get added without going through the > hotspot review process. > > Allowing any application or framework to add a DCMD changes this > VM centric view in a way that concerns me. This approach allows a > DCMD to pretty much do anything (java security not withstanding). > App writers could even use them to provide a user facing > interface. For example, if an app has some sort internal database, > it could allow users to query it via a DCMD, and maybe even > suggest that users write simple shell scripts that use jcmd to do > these queries. Allowing this type of non-diagnostic usage seems > like a path we don't want to go down, yet I don't see how it can > be prevented once you allow applications to add DCMDs. > > Chris > > On 10/25/21 1:37 AM, Denghui Dong wrote: > 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 > > From stuefe at openjdk.java.net Wed Nov 10 06:47:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 10 Nov 2021 06:47:39 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 06:19:56 GMT, David Holmes wrote: > It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: Your link did not work, I generated them and put them here for reviewer convenience: https://gist.github.com/tstuefe/8bd16a64061537d23e9ee556c7bd2965 Looks good. Most of the commands are ours (SAPs), but I had no idea that man pages existed. > > There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. > jcmd commands in general feel a bit anarchic. Different styles etc. But I fear that cannot be changed because of backward compatibility. Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6271 From rrich at openjdk.java.net Wed Nov 10 07:40:53 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 10 Nov 2021 07:40:53 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 Wed, 10 Nov 2021 01:27:40 GMT, Serguei Spitsyn wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment as suggested by Chris. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2194: > >> 2192: debugMonitorExit(threadLock); >> 2193: eventHandler_lock(); >> 2194: debugMonitorEnter(threadLock); > > The lines 2192-2194 look like a hack to me. > But I see you have filed an enhancement to fix this. > I'm okay to address it later. Thanks for looking at this Serguei. I agree that this part looks a little odd. It is still correct, though, and the changes are limited to the hardly used code responsible for handling j.l.Thread.resume() calls which is a good thing IMHO. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From jwilhelm at openjdk.java.net Wed Nov 10 09:55:06 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 10 Nov 2021 09:55:06 GMT Subject: RFR: 8276930: Update ProblemList Message-ID: Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. ------------- Commit messages: - Fixed duplicates Changes: https://git.openjdk.java.net/jdk/pull/6328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276930 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6328/head:pull/6328 PR: https://git.openjdk.java.net/jdk/pull/6328 From rrich at openjdk.java.net Wed Nov 10 09:55:33 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 10 Nov 2021 09:55:33 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 Wed, 10 Nov 2021 01:24:58 GMT, Serguei Spitsyn wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment as suggested by Chris. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2189: > >> 2187: >> 2188: /* >> 2189: * trackAppResume() (indirectly) aquires handlerLock. For proper lock > > I'd suggest to get rid of '()' brackets in this comment line, so it will be: > `* trackAppResume indirectly aquires handlerLock. For proper lock` Sure. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Nov 10 09:55:30 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 10 Nov 2021 09:55:30 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v11] 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 Serguei. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/3383a236..85dfaef1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=09-10 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 rschmelter at openjdk.java.net Wed Nov 10 10:05:45 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Wed, 10 Nov 2021 10:05:45 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. LGTM src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 812: > 810: { > 811: jthread resumer = evinfo->thread; > 812: ThreadNode *node; You could move the declaration into the if() block below, since it is not needed elsewhere. src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2192: > 2190: * ordering handlerLock has to be acquired before threadLock. > 2191: */ > 2192: debugMonitorExit(threadLock); You could move this to the if (resumer != NULL) block, since otherwise all the locking and unlocking is not needed anyways as far as I can see. ------------- Marked as reviewed by rschmelter (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5849 From jwilhelm at openjdk.java.net Wed Nov 10 10:41:56 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 10 Nov 2021 10:41:56 GMT Subject: RFR: 8276930: Update ProblemList [v2] In-Reply-To: References: Message-ID: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> > Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Moved non-instrument tests to the right place ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6328/files - new: https://git.openjdk.java.net/jdk/pull/6328/files/e0498532..38186d0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6328&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6328&range=00-01 Stats: 9 lines in 1 file changed: 4 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6328/head:pull/6328 PR: https://git.openjdk.java.net/jdk/pull/6328 From kevinw at openjdk.java.net Wed Nov 10 11:49:47 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 10 Nov 2021 11:49:47 GMT Subject: RFR: 8276930: Update ProblemList [v2] In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> References: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> Message-ID: On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson wrote: >> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Moved non-instrument tests to the right place Serviceability tidyup looks good to me. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/6328 From sspitsyn at openjdk.java.net Wed Nov 10 11:54:41 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 11:54:41 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v11] In-Reply-To: References: <7EGMDxENpiAhteL97_U3vmzoQXFcX546D4CzdZpy4c8=.2ef7ec9e-f004-47db-a59e-e88e8f4274a3@github.com> Message-ID: On Wed, 10 Nov 2021 09:55:30 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 Serguei. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From sspitsyn at openjdk.java.net Wed Nov 10 12:44:41 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 12:44:41 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace In-Reply-To: References: Message-ID: <7gYL85rBe8eKvM0anhb3qhZ5Y7xaUFsWwD9JeO1AioI=.b818affe-36fd-404a-8d6b-45ab93c8fab3@github.com> On Thu, 7 Oct 2021 12:42:48 GMT, Aleksey Shipilev wrote: > 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` src/hotspot/cpu/zero/frame_zero.cpp line 174: > 172: > 173: // validate locals > 174: address locals = (address) *interpreter_frame_locals_addr(); Unneeded spaces around '(address)'. ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From sspitsyn at openjdk.java.net Wed Nov 10 12:50:38 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 12:50:38 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace In-Reply-To: References: Message-ID: <68Lgv_Hwls0iUcUZwRMANWQi7TEYT4K1XFPRZyB071o=.33d613b4-207f-41b8-b976-6edb4ba9eb48@github.com> On Thu, 7 Oct 2021 12:42:48 GMT, Aleksey Shipilev wrote: > 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` Hi Aleksey, Thank you for the update. It looks pretty good to me. I've inlined a couple of minor comments. Also, I hope, you will update the copyright years. Thanks, Serguei src/hotspot/share/prims/forte.cpp line 348: > 346: return false; > 347: } > 348: #endif Could you, please, add some simple comments explaining each case at lines: 325, 329 and 336? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5848 From rrich at openjdk.java.net Wed Nov 10 14:02:18 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 10 Nov 2021 14:02:18 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 Mon, 8 Nov 2021 19:10:23 GMT, Ralf Schmelter wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment as suggested by Chris. > > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 812: > >> 810: { >> 811: jthread resumer = evinfo->thread; >> 812: ThreadNode *node; > > You could move the declaration into the if() block below, since it is not needed elsewhere. Done. > src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2192: > >> 2190: * ordering handlerLock has to be acquired before threadLock. >> 2191: */ >> 2192: debugMonitorExit(threadLock); > > You could move this to the if (resumer != NULL) block, since otherwise all the locking and unlocking is not needed anyways as far as I can see. Done. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Wed Nov 10 14:02:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 10 Nov 2021 14:02:11 GMT Subject: RFR: 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend [v12] 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: Changes based on Ralf's feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5849/files - new: https://git.openjdk.java.net/jdk/pull/5849/files/85dfaef1..1da43f79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5849&range=10-11 Stats: 28 lines in 1 file changed: 9 ins; 10 del; 9 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 shade at openjdk.java.net Wed Nov 10 16:26:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 16:26:10 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v2] In-Reply-To: References: 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` Aleksey Shipilev 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: - Review feedback - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - Initial work: runs async-profiler successfully ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5848/files - new: https://git.openjdk.java.net/jdk/pull/5848/files/5575516c..8e25258d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=00-01 Stats: 888778 lines in 1818 files changed: 455790 ins; 426281 del; 6707 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 shade at openjdk.java.net Wed Nov 10 16:26:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 16:26:16 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v2] In-Reply-To: <7gYL85rBe8eKvM0anhb3qhZ5Y7xaUFsWwD9JeO1AioI=.b818affe-36fd-404a-8d6b-45ab93c8fab3@github.com> References: <7gYL85rBe8eKvM0anhb3qhZ5Y7xaUFsWwD9JeO1AioI=.b818affe-36fd-404a-8d6b-45ab93c8fab3@github.com> Message-ID: <5Z7ibS9XSydk2okYR911xl6Q0GSz7gEzZbp0MW7_Edo=.0a86e320-8dd3-4216-ae79-818df7cd6b38@github.com> On Wed, 10 Nov 2021 12:41:44 GMT, Serguei Spitsyn wrote: >> Aleksey Shipilev 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: >> >> - Review feedback >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Initial work: runs async-profiler successfully > > src/hotspot/cpu/zero/frame_zero.cpp line 174: > >> 172: >> 173: // validate locals >> 174: address locals = (address) *interpreter_frame_locals_addr(); > > Unneeded spaces around '(address)'. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From shade at openjdk.java.net Wed Nov 10 16:38:57 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 16:38:57 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v3] In-Reply-To: References: 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` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: More reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5848/files - new: https://git.openjdk.java.net/jdk/pull/5848/files/8e25258d..68ef4b63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=01-02 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 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 shade at openjdk.java.net Wed Nov 10 16:38:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 10 Nov 2021 16:38:58 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v3] In-Reply-To: <68Lgv_Hwls0iUcUZwRMANWQi7TEYT4K1XFPRZyB071o=.33d613b4-207f-41b8-b976-6edb4ba9eb48@github.com> References: <68Lgv_Hwls0iUcUZwRMANWQi7TEYT4K1XFPRZyB071o=.33d613b4-207f-41b8-b976-6edb4ba9eb48@github.com> Message-ID: On Wed, 10 Nov 2021 12:44:16 GMT, Serguei Spitsyn wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> More reviews > > src/hotspot/share/prims/forte.cpp line 348: > >> 346: return false; >> 347: } >> 348: #endif > > Could you, please, add some simple comments explaining each case at lines: 325, 329 and 336? See new commits! ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From cjplummer at openjdk.java.net Wed Nov 10 16:46:34 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 10 Nov 2021 16:46:34 GMT Subject: RFR: 8276930: Update ProblemList [v2] In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> References: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> Message-ID: On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson wrote: >> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Moved non-instrument tests to the right place test/jdk/ProblemList.txt line 789: > 787: # svc_tools > 788: > 789: sun/tools/jhsdb/BasicLauncherTest.java 8228649 linux-ppc64,linux-ppc64le 8228649 is also resolved. Maybe this isn't an issue anymore. Would need to ask someone on the PPC team. ------------- PR: https://git.openjdk.java.net/jdk/pull/6328 From cjplummer at openjdk.java.net Wed Nov 10 17:16:36 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 10 Nov 2021 17:16:36 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: <5-WQF7w5tTXASWRQ7Z_jwj-jiPyWrBC9XwX4sDEBJpo=.581ffe9f-d8f3-4cab-b7c4-7c6115c81f4c@github.com> On Fri, 5 Nov 2021 06:19:56 GMT, David Holmes wrote: > It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: > > https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html > > Summary of changes: > > New Commands: > - Compiler.perfmap > - System.trim_native_heap > - VM.cds > - VM.classloaders > - VM.events > - VM.metaspace > > Missing flags: > - GC.class_histogram -parallel > - GC.heap_dump - gz and overwrite options > - Thread.print -e > > There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. > > Thanks, > David While skimming through the entire man page, I stumbled across `VM.class_hierarchy`, a dcmd I wrote long ago. It says the following: -s: (Optional) If a class name is specified, it prints the subclasses. If the class name is not specified, only the superclasses are printed. (BOOLEAN, false) I couldn't decipher what this really meant, so I ran the dcmd and it became more obvious how the option worked, and also became obvious that the above is wrong. The help output has it right: -s : [optional] If a classname is specified, print its subclasses. Otherwise only its superclasses are printed. (BOOLEAN, false) So `jcmd VM.class_hierarchy Throwable` just prints: java.lang.Object/null |--java.lang.Throwable/null Whereas `jcmd VM.class_hierarchy -s Throwable` not only prints the above, but includes the hierarchy of every subclass of Throwable. In the man page help, adding "If the class name is not specified" is wrong. The intent of the help output is "If the class name IS specified and -s IS NOT specified...". There are probably improvements that can be made to the help output, but as it stands the man page help is wrong and at the very least should revert back to the help output. If you want me to work on something a bit better than the help output, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From coleenp at openjdk.java.net Wed Nov 10 17:24:47 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 10 Nov 2021 17:24:47 GMT Subject: RFR: 8276658: Clean up JNI local handles code Message-ID: JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. Move the fields to JavaThread and adding JavaThread* argument. Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. The commits in this change have been performance tested individually and together with no meaningful differences from mainline. ------------- Commit messages: - The VM Thread creates handles on the caller thread, unless it runs out then it allocates a block on its own thread, which it never cleans up. Pass the caller thread to allocate_handle so that allocate_block will add to the right thread, which is a JavaThread. - Refactor pushing and popping JNIHandleBlocks. - Remove JNIHandleBlock global freelists and Mutex - Move active_handles to JavaThread. Changes: https://git.openjdk.java.net/jdk/pull/6336/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6336&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276658 Stats: 426 lines in 25 files changed: 77 ins; 302 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/6336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6336/head:pull/6336 PR: https://git.openjdk.java.net/jdk/pull/6336 From sspitsyn at openjdk.java.net Wed Nov 10 18:05:35 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 18:05:35 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v3] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 16:38:57 GMT, Aleksey Shipilev wrote: >> 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` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More reviews Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From kvn at openjdk.java.net Wed Nov 10 20:49:37 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 10 Nov 2021 20:49:37 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. Someone from serviceability group have to look on this test too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From kvn at openjdk.java.net Wed Nov 10 20:52:45 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 10 Nov 2021 20:52:45 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. I am fine with changes. What testing was done? What testing tiers were run? ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From sspitsyn at openjdk.java.net Wed Nov 10 22:35:34 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 22:35:34 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 128: > 126: > 127: Asserts.assertEQ( > 128: TriggerBuiltinExceptionsTest.caughtByJVMTIAgent(), caughtByJavaTest, What is the reason to use the class name prefix for methods? : TriggerBuiltinExceptionsTest.compileMethodOrThrow TriggerBuiltinExceptionsTest.methodToCompile TriggerBuiltinExceptionsTest.caughtByJVMTIAgent It is not really needed, tight? ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From sspitsyn at openjdk.java.net Wed Nov 10 22:42:33 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 10 Nov 2021 22:42:33 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. Hi Evgeny, New test looks good to me. I've inlined a couple of minor comments/suggestions. Thanks, Serguei test/hotspot/jtreg/compiler/jvmti/libTriggerBuiltinExceptions.cpp line 77: > 75: } > 76: > 77: } while (false); I'm not sure why the while (false) loop is needed. You can always return JNI_ERR instead of break in all places where the result != JVMTI_ERROR_NONE is detected and return JNI_OK at the end. Is it to for one-return style? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5889 From jwilhelm at openjdk.java.net Thu Nov 11 00:00:35 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 11 Nov 2021 00:00:35 GMT Subject: RFR: 8276930: Update ProblemList [v2] In-Reply-To: References: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> Message-ID: On Wed, 10 Nov 2021 16:42:37 GMT, Chris Plummer wrote: >> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved non-instrument tests to the right place > > test/jdk/ProblemList.txt line 789: > >> 787: # svc_tools >> 788: >> 789: sun/tools/jhsdb/BasicLauncherTest.java 8228649 linux-ppc64,linux-ppc64le > > 8228649 is also resolved. Maybe this isn't an issue anymore. Would need to ask someone on the PPC team. Yes, there were a couple of them that was duplicates of closed bugs, but this change only deals with duplicates. To actually remove the tests from the list I would need to run them for a while to make sure they pass now. That's a later task. ------------- PR: https://git.openjdk.java.net/jdk/pull/6328 From dholmes at openjdk.java.net Thu Nov 11 01:14:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 01:14:39 GMT Subject: RFR: 8276930: Update ProblemList [v2] In-Reply-To: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> References: <31Z-qfl6r6oUSerTO-Df5xnemuwG1VNUXTQLNJ6jGwo=.5d6a10f5-e7be-4f43-8ed3-7421e14525ef@github.com> Message-ID: On Wed, 10 Nov 2021 10:41:56 GMT, Jesper Wilhelmsson wrote: >> Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. > > Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: > > Moved non-instrument tests to the right place Hi Jesper, Switching to the alternate bug id looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6328 From jwilhelm at openjdk.java.net Thu Nov 11 01:17:40 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 11 Nov 2021 01:17:40 GMT Subject: Integrated: 8276930: Update ProblemList In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 09:30:38 GMT, Jesper Wilhelmsson wrote: > Update a few entries in the problemlist that refer to bugs that have been closed as duplicates. This pull request has now been integrated. Changeset: e27a67a9 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/e27a67a91647e584411a9ef57c0a028ab37af19b Stats: 17 lines in 1 file changed: 4 ins; 5 del; 8 mod 8276930: Update ProblemList Reviewed-by: kevinw, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6328 From dholmes at openjdk.java.net Thu Nov 11 04:15:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 04:15:37 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: <5-WQF7w5tTXASWRQ7Z_jwj-jiPyWrBC9XwX4sDEBJpo=.581ffe9f-d8f3-4cab-b7c4-7c6115c81f4c@github.com> References: <5-WQF7w5tTXASWRQ7Z_jwj-jiPyWrBC9XwX4sDEBJpo=.581ffe9f-d8f3-4cab-b7c4-7c6115c81f4c@github.com> Message-ID: <0b9YJG8ba3npDLyghznMqn3UgWFR_Y0t15z9huoRlE0=.72f9ee25-f25d-4645-a617-d4860529b935@github.com> On Wed, 10 Nov 2021 17:13:59 GMT, Chris Plummer wrote: >> It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: >> >> https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html >> >> Summary of changes: >> >> New Commands: >> - Compiler.perfmap >> - System.trim_native_heap >> - VM.cds >> - VM.classloaders >> - VM.events >> - VM.metaspace >> >> Missing flags: >> - GC.class_histogram -parallel >> - GC.heap_dump - gz and overwrite options >> - Thread.print -e >> >> There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. >> >> Thanks, >> David > > While skimming through the entire man page, I stumbled across `VM.class_hierarchy`, a dcmd I wrote long ago. It says the following: > > -s: (Optional) If a class name is specified, it prints the subclasses. If the class name > is not specified, only the superclasses are printed. (BOOLEAN, false) > > I couldn't decipher what this really meant, so I ran the dcmd and it became more obvious how the option worked, and also became obvious that the above is wrong. The help output has it right: > > -s : [optional] If a classname is specified, print its subclasses. Otherwise only its > superclasses are printed. (BOOLEAN, false) > > So `jcmd VM.class_hierarchy Throwable` just prints: > > java.lang.Object/null > |--java.lang.Throwable/null > > Whereas `jcmd VM.class_hierarchy -s Throwable` not only prints the above, but includes the hierarchy of every subclass of Throwable. > > In the man page help, adding "If the class name is not specified" is wrong. The intent of the help output is "If the class name IS specified and -s IS NOT specified...". There are probably improvements that can be made to the help output, but as it stands the man page help is wrong and at the very least should revert back to the help output. If you want me to work on something a bit better than the help output, I can do that. @plummercj seems to me that the help text is where the error was introduced. If you say "If x then .... Otherwise ..." the "otherwise" is equivalent to "not x" because X was the subject of the previous sentence. So the help text should not be using otherwise the way that it does as the subject is wrong - it wants the subject to the use of the -s option. What the help text should say is something like: -s: [optional] If a classname is specified print its subclasses. Without this option only the superclasses would be printed. ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From cjplummer at openjdk.java.net Thu Nov 11 04:35:35 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 11 Nov 2021 04:35:35 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: <0b9YJG8ba3npDLyghznMqn3UgWFR_Y0t15z9huoRlE0=.72f9ee25-f25d-4645-a617-d4860529b935@github.com> References: <5-WQF7w5tTXASWRQ7Z_jwj-jiPyWrBC9XwX4sDEBJpo=.581ffe9f-d8f3-4cab-b7c4-7c6115c81f4c@github.com> <0b9YJG8ba3npDLyghznMqn3UgWFR_Y0t15z9huoRlE0=.72f9ee25-f25d-4645-a617-d4860529b935@github.com> Message-ID: On Thu, 11 Nov 2021 04:12:54 GMT, David Holmes wrote: > -s: [optional] If a classname is specified print its subclasses. Without this option only the superclasses would be printed. Yes, wording like that would be clearer. How do you want to handle this? A new CR for both the help text and the man page, or do you think you can make both changes with this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From dholmes at openjdk.java.net Thu Nov 11 05:07:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 05:07:39 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 06:19:56 GMT, David Holmes wrote: > It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: > > https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html > > Summary of changes: > > New Commands: > - Compiler.perfmap > - System.trim_native_heap > - VM.cds > - VM.classloaders > - VM.events > - VM.metaspace > > Missing flags: > - GC.class_histogram -parallel > - GC.heap_dump - gz and overwrite options > - Thread.print -e > > There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. > > Thanks, > David A new CR please. And a review of this PR :) Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From cjplummer at openjdk.java.net Thu Nov 11 05:22:34 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 11 Nov 2021 05:22:34 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 06:19:56 GMT, David Holmes wrote: > It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: > > https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html > > Summary of changes: > > New Commands: > - Compiler.perfmap > - System.trim_native_heap > - VM.cds > - VM.classloaders > - VM.events > - VM.metaspace > > Missing flags: > - GC.class_histogram -parallel > - GC.heap_dump - gz and overwrite options > - Thread.print -e > > There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. > > Thanks, > David Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From cjplummer at openjdk.java.net Thu Nov 11 05:34:32 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 11 Nov 2021 05:34:32 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 05:04:49 GMT, David Holmes wrote: > A new CR please. And a review of this PR :) Thanks https://bugs.openjdk.java.net/browse/JDK-8276982 ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From dholmes at openjdk.java.net Thu Nov 11 05:57:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 05:57:41 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: <4jqAK0IYWkBy1sCEKvKWmGOqXB4OjhIPhybhTfE7Xxw=.1c9eb5e8-37e2-4bad-91f9-d5b72f6cdda6@github.com> On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 32: > 30: * > 31: * @build sun.hotspot.WhiteBox > 32: * @build compiler.jvmti.TriggerBuiltinExceptionsTest Explicit build directive should not be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From dholmes at openjdk.java.net Thu Nov 11 06:09:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 06:09:36 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. Just a couple of minor issues, not a review of functionality. test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 28: > 26: * @bug 8269574 > 27: * @summary Verifies that exceptions are reported correctly to JVMTI in the compiled code > 28: * @requires vm.jvmti You also require the JIT test/hotspot/jtreg/compiler/jvmti/TriggerBuiltinExceptionsTest.java line 59: > 57: public class TriggerBuiltinExceptionsTest { > 58: private static final WhiteBox WB = WhiteBox.getWhiteBox(); > 59: private static final int ITERATIONS = 30; //Arbitrary value, feel free to change Style nit: space after // ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From dholmes at openjdk.java.net Thu Nov 11 06:24:32 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 06:24:32 GMT Subject: RFR: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: <1iT0MrYqU10OEEThSIC7Sr86wBrPNn6sXvmAwGlsh-0=.5b3fb0e1-b2ff-434b-a7ae-63fed197b509@github.com> On Wed, 10 Nov 2021 06:44:17 GMT, Thomas Stuefe wrote: >> It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: >> >> https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html >> >> Summary of changes: >> >> New Commands: >> - Compiler.perfmap >> - System.trim_native_heap >> - VM.cds >> - VM.classloaders >> - VM.events >> - VM.metaspace >> >> Missing flags: >> - GC.class_histogram -parallel >> - GC.heap_dump - gz and overwrite options >> - Thread.print -e >> >> There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. >> >> Thanks, >> David > >> It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: > > Your link did not work, I generated them and put them here for reviewer convenience: https://gist.github.com/tstuefe/8bd16a64061537d23e9ee556c7bd2965 > > Looks good. Most of the commands are ours (SAPs), but I had no idea that man pages existed. > >> >> There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. >> > > jcmd commands in general feel a bit anarchic. Different styles etc. But I fear that cannot be changed because of backward compatibility. > > Thanks, Thomas Thanks for the reviews @tstuefe and @plummercj ! ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From dholmes at openjdk.java.net Thu Nov 11 07:10:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 07:10:35 GMT Subject: RFR: 8276658: Clean up JNI local handles code In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 17:16:29 GMT, Coleen Phillimore wrote: > JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. > Move the fields to JavaThread and adding JavaThread* argument. > Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. > Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. > The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. > The commits in this change have been performance tested individually and together with no meaningful differences from mainline. Hi Coleen, Nice cleanup and refactoring! I'm not familiar with all the details but the reshuffling looks good to me. One query and one minor issue below. Thanks, David src/hotspot/share/compiler/compileBroker.cpp line 2324: > 2322: // Remove the JNI handle block after the ciEnv destructor has run in > 2323: // the previous block. > 2324: pop_jni_handle_block(); Does the fact the JNIHandleMark destructor won't get executed until much later, at the end of this method, make any difference? src/hotspot/share/runtime/vmThread.hpp line 63: > 61: class VMThread: public NamedThread { > 62: private: > 63: volatile bool _is_running; I don't see this being initialized to false. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6336 From shade at openjdk.java.net Thu Nov 11 07:30:37 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 11 Nov 2021 07:30:37 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v3] In-Reply-To: References: Message-ID: <81d18oGgsBvytKRcjrO6lkygVY2G6wY-UHntuB47Fso=.084c545c-b9f1-4a07-a264-677cdbb9a2d2@github.com> On Wed, 10 Nov 2021 18:03:00 GMT, Serguei Spitsyn wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> More reviews > > Marked as reviewed by sspitsyn (Reviewer). Thank you, @sspitsyn! Any more reviews, anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From coleenp at openjdk.java.net Thu Nov 11 13:35:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 11 Nov 2021 13:35:34 GMT Subject: RFR: 8276658: Clean up JNI local handles code In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 06:35:59 GMT, David Holmes wrote: >> JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. >> Move the fields to JavaThread and adding JavaThread* argument. >> Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. >> Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. >> The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. >> The commits in this change have been performance tested individually and together with no meaningful differences from mainline. > > src/hotspot/share/runtime/vmThread.hpp line 63: > >> 61: class VMThread: public NamedThread { >> 62: private: >> 63: volatile bool _is_running; > > I don't see this being initialized to false. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Thu Nov 11 13:39:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 11 Nov 2021 13:39:35 GMT Subject: RFR: 8276658: Clean up JNI local handles code In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 06:52:45 GMT, David Holmes wrote: >> JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. >> Move the fields to JavaThread and adding JavaThread* argument. >> Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. >> Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. >> The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. >> The commits in this change have been performance tested individually and together with no meaningful differences from mainline. > > src/hotspot/share/compiler/compileBroker.cpp line 2324: > >> 2322: // Remove the JNI handle block after the ciEnv destructor has run in >> 2323: // the previous block. >> 2324: pop_jni_handle_block(); > > Does the fact the JNIHandleMark destructor won't get executed until much later, at the end of this method, make any difference? I don't think so because most of the rest of the function is logging and it doesn't seem to do anything with JNIHandles afterwards, so there are no handles created that shouldn't be removed in that code range. ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Thu Nov 11 13:58:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 11 Nov 2021 13:58:06 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v2] In-Reply-To: References: Message-ID: > JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. > Move the fields to JavaThread and adding JavaThread* argument. > Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. > Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. > The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. > The commits in this change have been performance tested individually and together with no meaningful differences from mainline. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add _is_running initialization. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6336/files - new: https://git.openjdk.java.net/jdk/pull/6336/files/239e9246..f31dfeee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6336&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6336&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6336/head:pull/6336 PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Thu Nov 11 13:58:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 11 Nov 2021 13:58:07 GMT Subject: RFR: 8276658: Clean up JNI local handles code In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 17:16:29 GMT, Coleen Phillimore wrote: > JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. > Move the fields to JavaThread and adding JavaThread* argument. > Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. > Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. > The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. > The commits in this change have been performance tested individually and together with no meaningful differences from mainline. Thank you for the code review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From dholmes at openjdk.java.net Thu Nov 11 22:14:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 11 Nov 2021 22:14:37 GMT Subject: Integrated: 8276265: jcmd man page is outdated In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 06:19:56 GMT, David Holmes wrote: > It was noticed that a number of updates to the jcmd subcommands (some new, some modified) had not been added to the manpage. The text was supplied by @tstuefe - thanks Thomas. I applied the changes to the closed markdown sources and regenerated the nroff file. For easier review I have generated a html version that can be viewed here: > > https://htmlpreview.github.io/https://github.com/dholmes-ora/jdk/blob/57c00815460ffef201239eafac322b4dd246da1b/jcmd.html > > Summary of changes: > > New Commands: > - Compiler.perfmap > - System.trim_native_heap > - VM.cds > - VM.classloaders > - VM.events > - VM.metaspace > > Missing flags: > - GC.class_histogram -parallel > - GC.heap_dump - gz and overwrite options > - Thread.print -e > > There are further improvements that could be made, some mentioned in the bug report. I also noticed a general confusion between arguments and options with some subcommands, but I did not try to address that. > > Thanks, > David This pull request has now been integrated. Changeset: 3445e50b Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/3445e50bd573857660908a964886f94714315f4c Stats: 153 lines in 1 file changed: 146 ins; 6 del; 1 mod 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/6271 From dholmes at openjdk.java.net Fri Nov 12 04:55:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 12 Nov 2021 04:55:34 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore wrote: >> JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. >> Move the fields to JavaThread and adding JavaThread* argument. >> Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. >> Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. >> The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. >> The commits in this change have been performance tested individually and together with no meaningful differences from mainline. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add _is_running initialization. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From stuefe at openjdk.java.net Fri Nov 12 10:05:45 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 12 Nov 2021 10:05:45 GMT Subject: RFR: JDK-8276983: Small fixes to DumpAllocStat::print_stats Message-ID: When looking at CDS code in the context of Lilliput, I had to spend some time in DumpAllocStat::print(). I noticed two small things which can be fixed independently: - the divide-by-zero check at lines 45ff is not needed, since `percent_of` does this already. It also can cause the asserts at the end of the function to fire wrongly. - About those asserts: it makes sense to flush the debug message before scope end, otherwise, we won't see the debug message if the asserts fire. If they fire, the debug message would be helpful. I also improved the assert message somewhat. I noticed that all sizes in this method are `int`, but left it that way because changing it would have too many ripple effects. I guess we won't get CDS archives beyond int_max any time soon. Thanks, Thomas ------------- Commit messages: - Small fixes to DumpAllocStat::print_stats Changes: https://git.openjdk.java.net/jdk/pull/6347/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6347&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276983 Stats: 13 lines in 1 file changed: 3 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6347.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6347/head:pull/6347 PR: https://git.openjdk.java.net/jdk/pull/6347 From pchilanomate at openjdk.java.net Fri Nov 12 15:15:35 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 12 Nov 2021 15:15:35 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore wrote: >> JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. >> Move the fields to JavaThread and adding JavaThread* argument. >> Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. >> Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. >> The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. >> The commits in this change have been performance tested individually and together with no meaningful differences from mainline. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add _is_running initialization. Hi Coleen, Cleanup looks good to me. Thanks, Patricio src/hotspot/share/jfr/dcmd/jfrDcmds.cpp line 181: > 179: JNIHandleMark jni_handle_management(THREAD); > 180: > 181: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(THREAD)); This method will call into Java below which already checks the thread is in vm so maybe this is not necessary. Even construct_dcmd_instance() has that assert. ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Fri Nov 12 16:22:05 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 12 Nov 2021 16:22:05 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v3] In-Reply-To: References: Message-ID: > JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. > Move the fields to JavaThread and adding JavaThread* argument. > Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. > Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. > The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. > The commits in this change have been performance tested individually and together with no meaningful differences from mainline. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove redundant assert. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6336/files - new: https://git.openjdk.java.net/jdk/pull/6336/files/f31dfeee..f24e32c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6336&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6336&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6336/head:pull/6336 PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Fri Nov 12 16:22:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 12 Nov 2021 16:22:10 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:58:06 GMT, Coleen Phillimore wrote: >> JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. >> Move the fields to JavaThread and adding JavaThread* argument. >> Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. >> Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. >> The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. >> The commits in this change have been performance tested individually and together with no meaningful differences from mainline. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add _is_running initialization. Thanks for the review, Patricio and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Fri Nov 12 16:22:15 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 12 Nov 2021 16:22:15 GMT Subject: RFR: 8276658: Clean up JNI local handles code [v2] In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 15:08:24 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add _is_running initialization. > > src/hotspot/share/jfr/dcmd/jfrDcmds.cpp line 181: > >> 179: JNIHandleMark jni_handle_management(THREAD); >> 180: >> 181: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_vm(THREAD)); > > This method will call into Java below which already checks the thread is in vm so maybe this is not necessary. Even construct_dcmd_instance() has that assert. You're right, it's doubly redundant. I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From coleenp at openjdk.java.net Fri Nov 12 16:22:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 12 Nov 2021 16:22:16 GMT Subject: Integrated: 8276658: Clean up JNI local handles code In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 17:16:29 GMT, Coleen Phillimore wrote: > JNI Local handles can only be created by JavaThread (there's an assert in make_local) but the fields are added to Thread. > Move the fields to JavaThread and adding JavaThread* argument. > Also, the global freelist isn't very useful now that global JNI handles don't use JNIHandleBlock, so the locking that claims incorrectly to block for safepoint is removed. > Lastly, there's at least 3 places that duplicate pushing a new JNIHandleBlock to the thread for temporarily adding JNI local handles. These have been moved to common code with a JNIHandleMark object, moved from jvmci code. > The commits are separate to help reviewing, but the entire change has been tested together with tier1-6. > The commits in this change have been performance tested individually and together with no meaningful differences from mainline. This pull request has now been integrated. Changeset: 3b2585c0 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/3b2585c02bd9d66cc2c8b2d5c16e9a48f4280d07 Stats: 425 lines in 25 files changed: 75 ins; 302 del; 48 mod 8276658: Clean up JNI local handles code Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/6336 From kvn at openjdk.java.net Fri Nov 12 17:35:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 12 Nov 2021 17:35:40 GMT Subject: RFR: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. I will leave approval to @sspitsyn and @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From dholmes at openjdk.java.net Mon Nov 15 00:42:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 15 Nov 2021 00:42:35 GMT Subject: RFR: JDK-8276983: Small fixes to DumpAllocStat::print_stats In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 06:15:32 GMT, Thomas Stuefe wrote: > When looking at CDS code in the context of Lilliput, I had to spend some time in DumpAllocStat::print(). I noticed two small things which can be fixed independently: > > - the divide-by-zero check at lines 45ff is not needed, since `percent_of` does this already. It also can cause the asserts at the end of the function to fire wrongly. > > - About those asserts: it makes sense to flush the debug message before scope end, otherwise, we won't see the debug message if the asserts fire. If they fire, the debug message would be helpful. > > I also improved the assert message somewhat. I noticed that all sizes in this method are `int`, but left it that way because changing it would have too many ripple effects. I guess we won't get CDS archives beyond int_max any time soon. > > Thanks, Thomas Hi Thomas, Seems okay. Relying on percent_of rather than passing in 1 does seem to change what will be output, but AFAICS we should never be able to pass zero in the first place. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6347 From iklam at openjdk.java.net Mon Nov 15 06:30:36 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 15 Nov 2021 06:30:36 GMT Subject: RFR: JDK-8276983: Small fixes to DumpAllocStat::print_stats In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 06:15:32 GMT, Thomas Stuefe wrote: > When looking at CDS code in the context of Lilliput, I had to spend some time in DumpAllocStat::print(). I noticed two small things which can be fixed independently: > > - the divide-by-zero check at lines 45ff is not needed, since `percent_of` does this already. It also can cause the asserts at the end of the function to fire wrongly. > > - About those asserts: it makes sense to flush the debug message before scope end, otherwise, we won't see the debug message if the asserts fire. If they fire, the debug message would be helpful. > > I also improved the assert message somewhat. I noticed that all sizes in this method are `int`, but left it that way because changing it would have too many ripple effects. I guess we won't get CDS archives beyond int_max any time soon. > > Thanks, Thomas LGTM. Good clean up. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6347 From stuefe at openjdk.java.net Mon Nov 15 06:50:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 15 Nov 2021 06:50:42 GMT Subject: RFR: JDK-8276983: Small fixes to DumpAllocStat::print_stats In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 00:39:53 GMT, David Holmes wrote: >> When looking at CDS code in the context of Lilliput, I had to spend some time in DumpAllocStat::print(). I noticed two small things which can be fixed independently: >> >> - the divide-by-zero check at lines 45ff is not needed, since `percent_of` does this already. It also can cause the asserts at the end of the function to fire wrongly. >> >> - About those asserts: it makes sense to flush the debug message before scope end, otherwise, we won't see the debug message if the asserts fire. If they fire, the debug message would be helpful. >> >> I also improved the assert message somewhat. I noticed that all sizes in this method are `int`, but left it that way because changing it would have too many ripple effects. I guess we won't get CDS archives beyond int_max any time soon. >> >> Thanks, Thomas > > Hi Thomas, > > Seems okay. Relying on percent_of rather than passing in 1 does seem to change what will be output, but AFAICS we should never be able to pass zero in the first place. > > Thanks, > David Thanks @dholmes-ora and @iklam ! ------------- PR: https://git.openjdk.java.net/jdk/pull/6347 From stuefe at openjdk.java.net Mon Nov 15 06:50:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 15 Nov 2021 06:50:43 GMT Subject: Integrated: JDK-8276983: Small fixes to DumpAllocStat::print_stats In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 06:15:32 GMT, Thomas Stuefe wrote: > When looking at CDS code in the context of Lilliput, I had to spend some time in DumpAllocStat::print(). I noticed two small things which can be fixed independently: > > - the divide-by-zero check at lines 45ff is not needed, since `percent_of` does this already. It also can cause the asserts at the end of the function to fire wrongly. > > - About those asserts: it makes sense to flush the debug message before scope end, otherwise, we won't see the debug message if the asserts fire. If they fire, the debug message would be helpful. > > I also improved the assert message somewhat. I noticed that all sizes in this method are `int`, but left it that way because changing it would have too many ripple effects. I guess we won't get CDS archives beyond int_max any time soon. > > Thanks, Thomas This pull request has now been integrated. Changeset: 296780c7 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/296780c7ae5c129d24997007600f428b697d3365 Stats: 13 lines in 1 file changed: 3 ins; 8 del; 2 mod 8276983: Small fixes to DumpAllocStat::print_stats Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/6347 From rrich at openjdk.java.net Mon Nov 15 07:05:43 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 15 Nov 2021 07:05:43 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 17:48:36 GMT, Chris Plummer wrote: >> 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). Thanks for the reviews @plummercj, @sspitsyn, @schmelter-sap! ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From rrich at openjdk.java.net Mon Nov 15 07:05:44 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 15 Nov 2021 07:05:44 GMT Subject: Integrated: 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: 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 This pull request has now been integrated. Changeset: ca2efb73 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/ca2efb73f59112d9be2ec29db405deb4c58dd435 Stats: 333 lines in 2 files changed: 314 ins; 14 del; 5 mod 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Reviewed-by: cjplummer, sspitsyn, rschmelter ------------- PR: https://git.openjdk.java.net/jdk/pull/5849 From stuefe at openjdk.java.net Mon Nov 15 07:49:44 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 15 Nov 2021 07:49:44 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Message-ID: jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, jstring command, dcmdArgInfo* infoArray) but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. ------------- Testing: - manual tests with artificially induced error in one dcmd for debug, release - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) ------------- Commit messages: - explicitly pass output array size and check it in hotspot Changes: https://git.openjdk.java.net/jdk/pull/6363/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6363&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277029 Stats: 18 lines in 3 files changed: 8 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6363.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6363/head:pull/6363 PR: https://git.openjdk.java.net/jdk/pull/6363 From dholmes at openjdk.java.net Mon Nov 15 10:04:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 15 Nov 2021 10:04:39 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes In-Reply-To: References: Message-ID: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> On Fri, 12 Nov 2021 08:25:04 GMT, Thomas Stuefe wrote: > jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: > > > void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, > jstring command, dcmdArgInfo* infoArray) > > > but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. > > Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. > > ------------- > > Testing: > - manual tests with artificially induced error in one dcmd for debug, release > - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) Hi Thomas, Sorry but only half of this makes sense to me. Cheers, David src/hotspot/share/services/management.cpp line 1968: > 1966: > 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds, > 1968: dcmdInfo* infoArray, jint count)) I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ? src/hotspot/share/services/management.cpp line 2022: > 2020: > 2021: JVM_ENTRY(void, jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, > 2022: jstring command, dcmdArgInfo* infoArray, jint count)) This one makes sense because you verify that the external expectation about the arg count matches the actual internal representation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From stuefe at openjdk.java.net Mon Nov 15 10:21:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 15 Nov 2021 10:21:43 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes In-Reply-To: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> References: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> Message-ID: <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com> On Mon, 15 Nov 2021 09:59:44 GMT, David Holmes wrote: >> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) > > src/hotspot/share/services/management.cpp line 1968: > >> 1966: >> 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds, >> 1968: dcmdInfo* infoArray, jint count)) > > I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ? Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part. ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From duke at openjdk.java.net Mon Nov 15 18:17:50 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Nov 2021 18:17:50 GMT Subject: RFR: 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi In-Reply-To: References: Message-ID: <5yBIeoec6glMc0gGB_QbTxRdT--fR28TeAH6YCBM2Hk=.a9ef751f-db42-4ef3-871d-ce9b56a6223d@github.com> On Thu, 23 Sep 2021 18:04:34 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.jdi module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > Similar cleanups > 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming > 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base keep open ------------- PR: https://git.openjdk.java.net/jdk/pull/5659 From duke at openjdk.java.net Mon Nov 15 18:17:48 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Nov 2021 18:17:48 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. keep open ------------- PR: https://git.openjdk.java.net/jdk/pull/5978 From cjplummer at openjdk.java.net Mon Nov 15 18:28:33 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 15 Nov 2021 18:28:33 GMT Subject: RFR: 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 18:04:34 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.jdi module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > Similar cleanups > 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming > 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base Are you just waiting for a sponsor? ------------- PR: https://git.openjdk.java.net/jdk/pull/5659 From duke at openjdk.java.net Mon Nov 15 19:09:38 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Nov 2021 19:09:38 GMT Subject: RFR: 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 18:04:34 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.jdi module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > Similar cleanups > 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming > 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base Yep. ------------- PR: https://git.openjdk.java.net/jdk/pull/5659 From cjplummer at openjdk.java.net Mon Nov 15 19:16:38 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 15 Nov 2021 19:16:38 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 cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5978 From duke at openjdk.java.net Mon Nov 15 19:17:45 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Nov 2021 19:17:45 GMT Subject: Integrated: 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 18:04:34 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.jdi module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > Similar cleanups > 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming > 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base This pull request has now been integrated. Changeset: db0c8d52 Author: Andrey Turbanov Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/db0c8d522704d2e12bce4ebeb9297b57e3789f4f Stats: 59 lines in 20 files changed: 0 ins; 13 del; 46 mod 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5659 From duke at openjdk.java.net Mon Nov 15 19:23:46 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Nov 2021 19:23:46 GMT Subject: Integrated: 8275385: Change nested classes in jdk.jdi to static nested classes In-Reply-To: References: Message-ID: <2WTQ96fp09G4ytKovfH5lgvdiDAsPTzWl2yrBjIsFjQ=.2024ef4e-029a-4f2a-ab26-31d96553e034@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. This pull request has now been integrated. Changeset: 7a870418 Author: Andrey Turbanov Committer: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/7a870418a3e8de3b290ba71cbe4ca7979ec029f9 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod 8275385: Change nested classes in jdk.jdi to static nested classes Reviewed-by: sspitsyn, amenkov, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5978 From sspitsyn at openjdk.java.net Tue Nov 16 01:57:37 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 16 Nov 2021 01:57:37 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes In-Reply-To: <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com> References: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com> Message-ID: On Mon, 15 Nov 2021 10:18:52 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/management.cpp line 1968: >> >>> 1966: >>> 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds, >>> 1968: dcmdInfo* infoArray, jint count)) >> >> I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ? > > Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. > > Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part. Hi Thomas, I kind of agree with David. The symmetry does not help in this case as it creates a bit of confusion. :) Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From lmesnik at openjdk.java.net Tue Nov 16 02:10:49 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 16 Nov 2021 02:10:49 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 Message-ID: The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. This fix also prints references to inspected class. ------------- Commit messages: - fix Changes: https://git.openjdk.java.net/jdk/pull/6402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265796 Stats: 11 lines in 3 files changed: 6 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6402/head:pull/6402 PR: https://git.openjdk.java.net/jdk/pull/6402 From dholmes at openjdk.java.net Tue Nov 16 02:15:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 16 Nov 2021 02:15:34 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes In-Reply-To: References: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com> Message-ID: On Tue, 16 Nov 2021 01:54:28 GMT, Serguei Spitsyn wrote: >> Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. >> >> Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part. > > Hi Thomas, > > I kind of agree with David. > The symmetry does not help in this case as it creates a bit of confusion. :) > > Thanks, > Serguei Thomas, please drop this part. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From cjplummer at openjdk.java.net Tue Nov 16 02:22:36 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 16 Nov 2021 02:22:36 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:03:46 GMT, Leonid Mesnik wrote: > The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. > This fix also prints references to inspected class. test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java line 103: > 101: for (ObjectReference ref: classObjectReference.referringObjects(0)) { > 102: log.complain(ref); > 103: } Did you intend to leave this in? If yes, shouldn't `log.display()` be used? test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002a.java line 2: > 1: /* > 2: * Copyright (c) 2007, 2021, Oracle and/or its affiliates. All rights reserved. No changes in this file other than the copyright update. I think it can be undone. ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Tue Nov 16 02:45:13 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 16 Nov 2021 02:45:13 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: > The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. > This fix also prints references to inspected class. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6402/files - new: https://git.openjdk.java.net/jdk/pull/6402/files/f4865603..196534ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6402/head:pull/6402 PR: https://git.openjdk.java.net/jdk/pull/6402 From cjplummer at openjdk.java.net Tue Nov 16 02:55:38 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 16 Nov 2021 02:55:38 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From dholmes at openjdk.java.net Tue Nov 16 04:36:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 16 Nov 2021 04:36:34 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated Hi Leonid, Where is the reflective call that you are referring to? I'm wondering why the MH based reflection holds a reference where the previous reflection implementation would not? And whether this is an unintended change in behaviour for core reflection. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From stuefe at openjdk.java.net Tue Nov 16 06:26:08 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 16 Nov 2021 06:26:08 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: References: Message-ID: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> > jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: > > > void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, > jstring command, dcmdArgInfo* infoArray) > > > but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. > > Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. > > ------------- > > Testing: > - manual tests with artificially induced error in one dcmd for debug, release > - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Remove changes to GetDiagnosticCommandInfo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6363/files - new: https://git.openjdk.java.net/jdk/pull/6363/files/65dad518..3bdc6c89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6363&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6363&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6363.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6363/head:pull/6363 PR: https://git.openjdk.java.net/jdk/pull/6363 From stuefe at openjdk.java.net Tue Nov 16 06:26:11 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 16 Nov 2021 06:26:11 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> References: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com> Message-ID: On Mon, 15 Nov 2021 10:01:33 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove changes to GetDiagnosticCommandInfo > > Hi Thomas, > > Sorry but only half of this makes sense to me. > > Cheers, > David @dholmes-ora, @sspitsyn Thanks for your reviews. I removed the changes to GetDiagnosticCommandInfo as requested. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From sspitsyn at openjdk.java.net Tue Nov 16 06:40:35 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 16 Nov 2021 06:40:35 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> References: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> Message-ID: On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe wrote: >> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove changes to GetDiagnosticCommandInfo Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6363 From dholmes at openjdk.java.net Tue Nov 16 07:40:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 16 Nov 2021 07:40:36 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> References: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> Message-ID: <-G3K5V_UAAVM6-e_hiTXRpdxpbWe0W2uSPGpifLV9d0=.7fd11fdc-319c-468b-a63b-ac18c2c3acf0@github.com> On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe wrote: >> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove changes to GetDiagnosticCommandInfo Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6363 From stuefe at openjdk.java.net Tue Nov 16 09:52:42 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 16 Nov 2021 09:52:42 GMT Subject: RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes [v2] In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> References: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com> Message-ID: <3OOui2hpFGXW7BvpMHVMk6MCkAOqeMzWDPF4UOmat-E=.f21f6a27-6b16-4a2a-96e0-865ef70cdf80@github.com> On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe wrote: >> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: >> >> >> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, >> jstring command, dcmdArgInfo* infoArray) >> >> >> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. >> >> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. >> >> ------------- >> >> Testing: >> - manual tests with artificially induced error in one dcmd for debug, release >> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove changes to GetDiagnosticCommandInfo Thanks David and Serguey ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From stuefe at openjdk.java.net Tue Nov 16 09:52:43 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 16 Nov 2021 09:52:43 GMT Subject: Integrated: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes In-Reply-To: References: Message-ID: <6n0IFXT7fiHk1z6WyJO-sVPkwtS0re9q1dZkmnvNRRc=.71b54340-3efe-4b58-b583-80335870ee12@github.com> On Fri, 12 Nov 2021 08:25:04 GMT, Thomas Stuefe wrote: > jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information: > > > void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env, > jstring command, dcmdArgInfo* infoArray) > > > but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter. > > Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here. > > ------------- > > Testing: > - manual tests with artificially induced error in one dcmd for debug, release > - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs) This pull request has now been integrated. Changeset: b8d33a2a Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb Stats: 9 lines in 3 files changed: 3 ins; 0 del; 6 mod 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6363 From duke at openjdk.java.net Tue Nov 16 11:16:41 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:16:41 GMT Subject: Integrated: 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd In-Reply-To: <88ut3mHpYFIH3LHWoaKk6y7LrhHye3dPCntSckRYhrI=.70138c33-ad16-4205-9818-23b6bf5f9c46@github.com> References: <88ut3mHpYFIH3LHWoaKk6y7LrhHye3dPCntSckRYhrI=.70138c33-ad16-4205-9818-23b6bf5f9c46@github.com> Message-ID: <69_W3QGWQxAXIEYYlP8kKGYOTv9WPhldMavAkcblAmY=.b5b66f3e-d5a0-44fe-a6fd-c42d5c3f4bb1@github.com> On Fri, 24 Sep 2021 07:30:02 GMT, Andrey Turbanov wrote: > There are few places in code where manual `for` loop is used with Iterator to iterate over Collection or Array. > 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. > > One strange thing I also noticed is static field `sun.tools.jstat.Parser#reservedWords`, which filled in `Parser` constructor. Reworked to initialize it once. This pull request has now been integrated. Changeset: 20f3872d Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/20f3872d1cd6257ab9c76bb998f8dc2d07bc1724 Stats: 44 lines in 6 files changed: 0 ins; 14 del; 30 mod 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/5673 From duke at openjdk.java.net Tue Nov 16 11:17:48 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:17:48 GMT Subject: Integrated: 8274168: Avoid String.compareTo == 0 to check String equality in java.management In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 20:39:51 GMT, Andrey Turbanov wrote: > Cleanup places, where String.compareTo is used to check String's equality. > Instead String.equals or switch expression could be used. They are faster and code is cleaner. This pull request has now been integrated. Changeset: a9cb8bdb Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/a9cb8bdbaac7241959805c491b6d13b6e14f8966 Stats: 30 lines in 2 files changed: 1 ins; 13 del; 16 mod 8274168: Avoid String.compareTo == 0 to check String equality in java.management Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5640 From duke at openjdk.java.net Tue Nov 16 11:19:46 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:19:46 GMT Subject: Integrated: 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat In-Reply-To: <6TTdEYIU3_JuhSRlrB000UfT6ILb9QBoRm_FJiwnxis=.06a13c5b-139b-4eeb-b7e4-f3f8932e6191@github.com> References: <6TTdEYIU3_JuhSRlrB000UfT6ILb9QBoRm_FJiwnxis=.06a13c5b-139b-4eeb-b7e4-f3f8932e6191@github.com> Message-ID: On Wed, 22 Sep 2021 19:20:35 GMT, Andrey Turbanov wrote: > In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!= 0`). > Instead of this, we can use String.equals calls. `String.equals` is faster and shorter. This pull request has now been integrated. Changeset: 0bc26837 Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/0bc268377ed5d2dd15bdd7283a77b59ad505e2b7 Stats: 18 lines in 7 files changed: 0 ins; 3 del; 15 mod 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5638 From duke at openjdk.java.net Tue Nov 16 11:20:46 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:20:46 GMT Subject: Integrated: 8274163: Use String.equals instead of String.compareTo in jdk.jcmd In-Reply-To: <97IDytjYycAd15y1b7OzbHYVqOYyRYPF3Shmvb-JpQY=.c510001a-e158-49b6-98dc-8bf7dec3cb3a@github.com> References: <97IDytjYycAd15y1b7OzbHYVqOYyRYPF3Shmvb-JpQY=.c510001a-e158-49b6-98dc-8bf7dec3cb3a@github.com> Message-ID: On Wed, 22 Sep 2021 19:14:03 GMT, Andrey Turbanov wrote: > In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!= 0`). > Instead of this, we can use String.equals calls. `String.equals` is faster and shorter. This pull request has now been integrated. Changeset: 9629627e Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/9629627e2c8021c254517ac5463cc66723175fd9 Stats: 35 lines in 4 files changed: 0 ins; 0 del; 35 mod 8274163: Use String.equals instead of String.compareTo in jdk.jcmd Reviewed-by: cjplummer, amenkov, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5637 From duke at openjdk.java.net Tue Nov 16 11:21:40 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:21:40 GMT Subject: Integrated: 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent In-Reply-To: References: Message-ID: <5blsSopNgFT4MEUxOOTTHp6MX73jzfUxOV0WTV-4dIw=.3793fdb3-3e6b-4dd1-8e5b-7e68bddb61f0@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 This pull request has now been integrated. Changeset: c06df25a Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/c06df25a4fb76ee65d3fa99ec0579ca4a406c345 Stats: 16 lines in 2 files changed: 0 ins; 8 del; 8 mod 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Reviewed-by: amenkov, cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5630 From duke at openjdk.java.net Tue Nov 16 11:22:39 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Nov 2021 11:22:39 GMT Subject: Integrated: 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module In-Reply-To: References: Message-ID: <0H6MSkm8X_gEWr3RZFuV6206SSeKyUpnhxLMwybzuQo=.8db72fee-8677-458b-954d-677ab2090c61@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. This pull request has now been integrated. Changeset: 1c45c8a0 Author: Andrey Turbanov Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207 Stats: 50 lines in 10 files changed: 0 ins; 32 del; 18 mod 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Reviewed-by: dfuchs, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/5552 From mchung at openjdk.java.net Tue Nov 16 17:06:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 16 Nov 2021 17:06:34 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated @lmesnik I also have the same question as David asks. If the reference is held via the MethodType, is TestClass1 part of the signature of the reflective call? ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Wed Nov 17 03:19:37 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 17 Nov 2021 03:19:37 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated The reference is held via MethodType. Debugee loads TestedClass1 using reflection. ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From sspitsyn at openjdk.java.net Wed Nov 17 08:19:36 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 17 Nov 2021 08:19:36 GMT Subject: RFR: 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test In-Reply-To: References: Message-ID: <31peUwJt73AuaqI8bw2MLspUWyHxZtWHcZqhHJpU8Jg=.1f0537f9-1e62-43e9-bff3-d6f6ad761294@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. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6170 From kevinw at openjdk.java.net Wed Nov 17 12:00:52 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 17 Nov 2021 12:00:52 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. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6170 From kevinw at openjdk.java.net Wed Nov 17 12:03:38 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 17 Nov 2021 12:03:38 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 2af9e597 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/2af9e5976fdf94afc7dbe5ad7827553818057bae Stats: 61 lines in 3 files changed: 14 ins; 46 del; 1 mod 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Reviewed-by: jiefu, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6170 From duke at openjdk.java.net Wed Nov 17 14:35:47 2021 From: duke at openjdk.java.net (duke) Date: Wed, 17 Nov 2021 14:35:47 GMT Subject: Withdrawn: 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 07:40:01 GMT, Fairoz Matte wrote: > 8206438: com/sun/jdi/FieldWatchpoints.java timeout intermittently This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5598 From shade at openjdk.java.net Wed Nov 17 15:40:36 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 17 Nov 2021 15:40:36 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v3] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:03:00 GMT, Serguei Spitsyn wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> More reviews > > Marked as reviewed by sspitsyn (Reviewer). > Thank you, @sspitsyn! Any more reviews, anyone? No other reviews? I'd like to integrate this soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From mchung at openjdk.java.net Wed Nov 17 19:06:45 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 17 Nov 2021 19:06:45 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated I think the test calls `Class::newInstance` to create an instance of `TestClass1`. The old implementation has one reference from `Constructor::clazz` field to `TestClass1`. The new implementation should have 2 new references: `MethodHandle::member` whose `MemberName::clazz` field references it and `MethodHandle::type` as the signature is `()TestClass1`. I would expect 2 additional references but not 1. @lmesnik does the debugger show MemberName::clazz? ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From dcubed at openjdk.java.net Wed Nov 17 21:12:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 17 Nov 2021 21:12:57 GMT Subject: RFR: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 Message-ID: A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. ------------- Commit messages: - 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 - 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 Changes: https://git.openjdk.java.net/jdk/pull/6438/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277346 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6438/head:pull/6438 PR: https://git.openjdk.java.net/jdk/pull/6438 From tschatzl at openjdk.java.net Wed Nov 17 21:20:43 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 17 Nov 2021 21:20:43 GMT Subject: RFR: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 20:43:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. Lgtm and trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6438 From bpb at openjdk.java.net Wed Nov 17 21:20:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Nov 2021 21:20:43 GMT Subject: RFR: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 20:43:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6438 From dcubed at openjdk.java.net Wed Nov 17 21:27:47 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 17 Nov 2021 21:27:47 GMT Subject: RFR: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 21:16:18 GMT, Thomas Schatzl wrote: >> A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. > > Lgtm and trivial @tschatzl and @bplb - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6438 From dcubed at openjdk.java.net Wed Nov 17 21:27:48 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 17 Nov 2021 21:27:48 GMT Subject: Integrated: 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 20:43:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList 7 serviceability/sa tests on macosx-x64. This pull request has now been integrated. Changeset: ce4471f8 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/ce4471f806e51bc9f9ad746b69ba490443947110 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 Reviewed-by: tschatzl, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/6438 From sspitsyn at openjdk.java.net Wed Nov 17 22:37:01 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 17 Nov 2021 22:37:01 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Message-ID: The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. The fix is to add a check for is_exiting() status into handshake closure do_thread() early. There following handshake closures are fixed by this update: - UpdateForPopTopFrameClosure - SetForceEarlyReturn - SetFramePopClosure ------------- Commit messages: - remove vmTestbase/nsk/jvmti/PopFrame/popframe011 from ProblemList.txt - fix 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with assert Changes: https://git.openjdk.java.net/jdk/pull/6440/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6440&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266593 Stats: 22 lines in 2 files changed: 10 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6440.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6440/head:pull/6440 PR: https://git.openjdk.java.net/jdk/pull/6440 From mdoerr at openjdk.java.net Wed Nov 17 23:02:48 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 17 Nov 2021 23:02:48 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: <9_lGsNSJueWi-Q6czgJUI8Ps9RuSK4sW8w4HO8uPfHU=.74eee17c-0d7e-4811-a6c6-fe90f60abd09@github.com> On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure LGTM. Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6440 From lmesnik at openjdk.java.net Thu Nov 18 00:35:41 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 18 Nov 2021 00:35:41 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From lmesnik at openjdk.java.net Thu Nov 18 02:46:37 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 18 Nov 2021 02:46:37 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated The debugger doesn't show MemberName::clazz, but I could see it in heapdump. It seems because it doesn't have GC root and should be here by JDI spec. And the MethodType is referred from 'static final ConcurrentWeakInternSet internTable = new ConcurrentWeakInternSet<>();?' from java/lang/invoke/MethodType.java. See ref tree: instance of java.lang.invoke.MethodType(id=883) instance of java.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry(id=887) instance of java.util.concurrent.ConcurrentHashMap$Node(id=888) instance of java.util.concurrent.ConcurrentHashMap$Node[1024] (id=890) instance of java.util.concurrent.ConcurrentHashMap(id=892) instance of java.lang.invoke.MethodType$ConcurrentWeakInternSet(id=894) instance of java.lang.Class(reflected class=java.lang.invoke.MethodType, id=72) ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From mchung at openjdk.java.net Thu Nov 18 02:56:43 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 18 Nov 2021 02:56:43 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated I believe the Constructor object is already GC'ed. This weak entry should be GC'ed in the subsequent GC cycles. Can you experiment to call `System::gc` in the debuggee and see what the reference count remains? ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Thu Nov 18 04:03:06 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 18 Nov 2021 04:03:06 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v3] In-Reply-To: References: Message-ID: > The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. > This fix also prints references to inspected class. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: force GC to clean weak references ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6402/files - new: https://git.openjdk.java.net/jdk/pull/6402/files/196534ed..04676dec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=01-02 Stats: 16 lines in 2 files changed: 9 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6402/head:pull/6402 PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Thu Nov 18 04:08:37 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 18 Nov 2021 04:08:37 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 04:03:06 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > force GC to clean weak references The triggering GC is enough to clean references. I've updated the test to force GC so we don't have this reference when checking referringObjects(long). ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From dholmes at openjdk.java.net Thu Nov 18 05:43:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Nov 2021 05:43:41 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Hi Leonid, Something seems amiss to me. First the checks for `java_thread->threadObj() == NULL` should not be necessary as the `threadObj` can never be NULL once it has been started and a non-started thread should not be possible by the time you reach the code doing the checks. Even if we nulled out `threadObj` for a terminated thread the `is_exiting` check would already handle that case. Second, if the target thread is exiting then surely the suspension check should return false and so we would already give a JVMTI_ERROR_THREAD_NOT_SUSPENDED error? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 06:52:40 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 06:52:40 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Martin and Leonid, thank you for quick review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 07:00:47 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 07:00:47 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: <3pe7ADvZ3z_slXMHOU3g0kIrhLcsLi0xDIeqIAAmmsM=.27039eee-1c1d-405b-a948-a0bda9acd287@github.com> On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Hi David, Thank you for reviewing this! I was also thinking about getting rid of the check `java_thread->threadObj() == NULL`. Then I've decided it is safe to keep it as it was in the original UpdateForPopTopFrameClosure implementation (but later in the code). I will remove it and retest the fix. > Second, if the target thread is exiting then surely the suspension check should return > false and so we would already give a JVMTI_ERROR_THREAD_NOT_SUSPENDED error? The assert ` assert(java_thread == _state->get_thread(), "Must be");` is fired one line before the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` code is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 07:08:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 07:08:15 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v2] In-Reply-To: References: Message-ID: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Serguei Spitsyn 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 - remove vmTestbase/nsk/jvmti/PopFrame/popframe011 from ProblemList.txt - fix 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with assert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6440/files - new: https://git.openjdk.java.net/jdk/pull/6440/files/64f22944..60e784ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6440&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6440&range=00-01 Stats: 1850 lines in 27 files changed: 1576 ins; 95 del; 179 mod Patch: https://git.openjdk.java.net/jdk/pull/6440.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6440/head:pull/6440 PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Thu Nov 18 07:37:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Nov 2021 07:37:42 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 07:08:15 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn 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 > - remove vmTestbase/nsk/jvmti/PopFrame/popframe011 from ProblemList.txt > - fix 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with assert Wouldn't it suffice to just move the assert then? ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 08:29:41 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 08:29:41 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 07:08:15 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn 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 > - remove vmTestbase/nsk/jvmti/PopFrame/popframe011 from ProblemList.txt > - fix 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with assert It does not look right to check other conditions if the JavaThread is exiting. So, I think, the `java_thread->is_exiting()` has to be checked first. Please, let me know if I miss anything. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 09:34:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 09:34:13 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6440/files - new: https://git.openjdk.java.net/jdk/pull/6440/files/60e784ec..435ab513 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6440&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6440&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6440.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6440/head:pull/6440 PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Thu Nov 18 09:58:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Nov 2021 09:58:39 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL IIUC these cases all require that the target is suspended else it is an error. If the target is_exiting then it is not suspended and therefore there is an error. The suspension check should already handle an exiting thread and so there is no need to explicitly add an is_exiting check. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 10:34:40 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 10:34:40 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: <_JMj789jxQAfiksYaaXNDkVxOyYr3bomNH_oUGDaSIk=.6e2435cc-78e5-4306-bfd7-d45f3766e51e@github.com> On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL It is not correct. At least, there is this case: /* non suspended and exiting thread */ case 6: set_watch_ev(1); /* watch JVMTI events */ popframe_err = (jvmti->PopFrame(frameThr)); /* explode the bomb */ set_watch_ev(0); /* ignore again JVMTI events */ if (popframe_err != JVMTI_ERROR_THREAD_NOT_SUSPENDED && popframe_err != JVMTI_ERROR_THREAD_NOT_ALIVE) { printf("TEST FAILED: the function PopFrame() returned the error %d: %s\n", popframe_err, TranslateError(popframe_err)); printf("\tBut it should return the error JVMTI_ERROR_THREAD_NOT_SUSPENDED or JVMTI_ERROR_THREAD_NOT_ALIVE.\n"); return STATUS_FAILED; } break; } In other cases, the test constructs cases so that the tested thread is alive when expected. The test was easily failing before in 10th of runs but now it does not fail in 100 runs. I'll try to run this test 1000 times on all platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Thu Nov 18 10:38:40 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 18 Nov 2021 10:38:40 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: <-6jHqTZU-MyvUMDaH_H7GFwBEP84d7IV2vrgLjS2n3w=.fa71006c-959e-4866-be9b-4de8c6525b6f@github.com> On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Also, if the target thread is exiting then the PopFrame should return error code `JVMTI_ERROR_THREAD_NOT_ALIVE`, but not `JVMTI_ERROR_THREAD_NOT_SUSPENDED`. It does not matter what this test is expecting. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Thu Nov 18 12:56:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Nov 2021 12:56:42 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL It seems somewhat subjective whether a thread that is exiting and thus still on its way to becoming "not alive" needs to report "not alive" versus "not suspended". As there appears to be no synchronization with the target in this case what stops it from transitioning to "is_exiting" the moment after the "is_exiting" check returns false, but before you hit the assertion? ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Thu Nov 18 13:11:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 18 Nov 2021 13:11:37 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Ignore that last question - the target is in a handshake so can't change state. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dcubed at openjdk.java.net Thu Nov 18 17:18:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 18 Nov 2021 17:18:39 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL src/hotspot/share/prims/jvmtiEnvBase.cpp line 1533: > 1531: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ > 1532: } > 1533: assert(java_thread == _state->get_thread(), "Must be"); This `assert()` is the site of the original test failure. I haven't yet looked at the locations of the other changes. The `is_exiting()` check is made under the protection of the `JvmtiThreadState_lock` so an unsuspended target thread that is exiting cannot reach the point where the `_state` is updated to clear the `JavaThread*` so we can't fail the `assert()` if the `is_exiting()` check has returned `false`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dcubed at openjdk.java.net Thu Nov 18 17:26:38 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 18 Nov 2021 17:26:38 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL I don't see a reason for the change in `SetForceEarlyReturn::doit()`, but I'm okay with the other changes. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1401: > 1399: if (!self) { > 1400: if (!java_thread->is_suspended()) { > 1401: _result = JVMTI_ERROR_THREAD_NOT_SUSPENDED; I don't see an obvious reason for this `is_exiting()` check. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1625: > 1623: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ > 1624: } > 1625: assert(_state->get_thread() == java_thread, "Must be"); The `assert()` on L1625 is subject to the same race as the original site. This `is_exiting()` check is made under the protection of the `JvmtiThreadState_lock` so it is sufficient to protect that `assert()`. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6440 From mchung at openjdk.java.net Thu Nov 18 17:31:42 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 18 Nov 2021 17:31:42 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 04:03:06 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > force GC to clean weak references Looks okay to me. Chris should re-review as I'm not close to the jdi tests. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6402 From duke at openjdk.java.net Thu Nov 18 18:14:01 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Thu, 18 Nov 2021 18:14:01 GMT Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent Message-ID: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> 8277413: Remove unused local variables in jdk.hotspot.agent ------------- Commit messages: - [PATCH] Remove unused local variables in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/6329/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6329&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277413 Stats: 26 lines in 8 files changed: 0 ins; 14 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6329.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6329/head:pull/6329 PR: https://git.openjdk.java.net/jdk/pull/6329 From bchristi at openjdk.java.net Thu Nov 18 22:55:02 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 18 Nov 2021 22:55:02 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal Message-ID: Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. The CSR has been approved. An automated test build+test run passes cleanly (FWIW :D ). ------------- Commit messages: - merge - @SuppressWarnings(removal) in Windows CKey.java - Add jls tag to runFinalization methods - Update wording of Object.finalize, new paragraph is now bold - update Object.finalize javadoc - update Object.finalize JavaDoc and @deprecated tag - Update Object.finalize deprecation message - Indicate that runFinalizers does nothing if finalization is disabled or removed - Fix @since on @Deprecated for java.lang.Enum - Clarify conditions for removal of Object.finalize method - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2 Changes: https://git.openjdk.java.net/jdk/pull/6465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276447 Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/6465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465 PR: https://git.openjdk.java.net/jdk/pull/6465 From sspitsyn at openjdk.java.net Fri Nov 19 10:11:39 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 19 Nov 2021 10:11:39 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:15:06 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1533: > >> 1531: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ >> 1532: } >> 1533: assert(java_thread == _state->get_thread(), "Must be"); > > This `assert()` is the site of the original test failure. I haven't yet > looked at the locations of the other changes. > > The `is_exiting()` check is made under the protection of the > `JvmtiThreadState_lock` so an unsuspended target thread that is > exiting cannot reach the point where the `_state` is updated to > clear the `JavaThread*` so we can't fail the `assert()` if the > `is_exiting()` check has returned `false`. Dan, Thank you for reviewing this! I'm not sure, I correctly understand you here. Are you saying that you agree with this change? In fact, the thread state can not be changed (and the assert fired) after the `is_exiting()` check is made even without `JvmtiThreadState_lock` protection because it is inside of a handshake execution. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Fri Nov 19 10:17:39 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 19 Nov 2021 10:17:39 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> On Thu, 18 Nov 2021 17:18:23 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1401: > >> 1399: if (!self) { >> 1400: if (!java_thread->is_suspended()) { >> 1401: _result = JVMTI_ERROR_THREAD_NOT_SUSPENDED; > > I don't see an obvious reason for this `is_exiting()` check. Okay. I see similar check in the `force_early_return()` function: if (state == NULL) { return JVMTI_ERROR_THREAD_NOT_ALIVE; } Would it better to replace it with this check instead? : if (java_thread->is_exiting()) { return JVMTI_ERROR_THREAD_NOT_ALIVE; } > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1625: > >> 1623: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ >> 1624: } >> 1625: assert(_state->get_thread() == java_thread, "Must be"); > > The `assert()` on L1625 is subject to the same race as the original site. > This `is_exiting()` check is made under the protection of the > `JvmtiThreadState_lock` so it is sufficient to protect that `assert()`. Okay, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From alanb at openjdk.java.net Fri Nov 19 17:31:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 19 Nov 2021 17:31:53 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From rriggs at openjdk.java.net Fri Nov 19 17:31:47 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 19 Nov 2021 17:31:47 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6465 From dcubed at openjdk.java.net Fri Nov 19 17:31:52 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Nov 2021 17:31:52 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Marked as reviewed by dcubed (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dcubed at openjdk.java.net Fri Nov 19 17:32:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 19 Nov 2021 17:32:19 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> References: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> Message-ID: On Fri, 19 Nov 2021 10:14:23 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1401: >> >>> 1399: if (!self) { >>> 1400: if (!java_thread->is_suspended()) { >>> 1401: _result = JVMTI_ERROR_THREAD_NOT_SUSPENDED; >> >> I don't see an obvious reason for this `is_exiting()` check. > > Okay. I see similar check in the `force_early_return()` function: > > if (state == NULL) { > return JVMTI_ERROR_THREAD_NOT_ALIVE; > } > > Would it better to replace it with this check instead? : > > if (java_thread->is_exiting()) { > return JVMTI_ERROR_THREAD_NOT_ALIVE; > } > > Removing this check and keep the one inside the handshake would be even better. > > I would also add this line for symmetry with two other cases: > > + MutexLocker mu(JvmtiThreadState_lock); > SetForceEarlyReturn op(state, value, tos); My point is that I don't see why you added the `is_exiting()` check since I don't see a race in that function, i.e., there's no `assert()` in this function that you need to protect. As for adding the `MutexLocker mu(JvmtiThreadState_lock)`, you'll have to analyze and justify why you would need to add that lock grab independent of this fix. I'm not seeing a bug there, but I haven't looked very closely. >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1533: >> >>> 1531: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ >>> 1532: } >>> 1533: assert(java_thread == _state->get_thread(), "Must be"); >> >> This `assert()` is the site of the original test failure. I haven't yet >> looked at the locations of the other changes. >> >> The `is_exiting()` check is made under the protection of the >> `JvmtiThreadState_lock` so an unsuspended target thread that is >> exiting cannot reach the point where the `_state` is updated to >> clear the `JavaThread*` so we can't fail the `assert()` if the >> `is_exiting()` check has returned `false`. > > Dan, > Thank you for reviewing this! > I'm not sure, I correctly understand you here. > Are you saying that you agree with this change? > In fact, the thread state can not be changed (and the assert fired) after the `is_exiting()` check is made even without `JvmtiThreadState_lock` protection because it is inside of a handshake execution. I agree with the `is_exiting()` check addition. I forgot that we're executing a Handshake `doit()` function. So we have a couple of reasons why an unsuspended target thread can't change from `!is_exiting()` to `is_exiting()` while we are in this function. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From lancea at openjdk.java.net Fri Nov 19 17:47:57 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 19 Nov 2021 17:47:57 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From darcy at openjdk.java.net Fri Nov 19 18:10:08 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 19 Nov 2021 18:10:08 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 18:10:09 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 18:10:09 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). src/java.base/share/classes/java/lang/Object.java line 481: > 479: * system resources or to perform other cleanup. > 480: *

> 481: * When running in a Java virtual machine in which finalization has been Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From bchristi at openjdk.java.net Fri Nov 19 18:19:10 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 19 Nov 2021 18:19:10 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung wrote: >> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. >> >> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. >> >> The CSR has been approved. >> An automated test build+test run passes cleanly (FWIW :D ). > > src/java.base/share/classes/java/lang/Object.java line 481: > >> 479: * system resources or to perform other cleanup. >> 480: *

>> 481: * When running in a Java virtual machine in which finalization has been > > Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From sspitsyn at openjdk.java.net Fri Nov 19 18:25:09 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 19 Nov 2021 18:25:09 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Dan, thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From sspitsyn at openjdk.java.net Fri Nov 19 18:54:22 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 19 Nov 2021 18:54:22 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: <0c7TGP1yfAhaJo8PLIkHEvNxZmlqIP-3Lr3tw_dO3wU=.71231bf7-4d0e-48d0-bb77-2e275ef0e652@github.com> On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL David, Thank you for your questions. I'm not sure if all of them are resolved though. :) Please, let me know if it is the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From mdoerr at openjdk.java.net Fri Nov 19 18:54:22 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 19 Nov 2021 18:54:22 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Still good. Thumbs up from my side. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6440 From mchung at openjdk.java.net Fri Nov 19 19:10:11 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:11 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From mchung at openjdk.java.net Fri Nov 19 19:10:12 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 19 Nov 2021 19:10:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> References: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com> Message-ID: On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote: >> src/java.base/share/classes/java/lang/Object.java line 481: >> >>> 479: * system resources or to perform other cleanup. >>> 480: *

>>> 481: * When running in a Java virtual machine in which finalization has been >> >> Disabling finalization is not part of the Java SE spec. This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc. > > The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal. That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS. Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled. This makes senses now. ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From serb at openjdk.java.net Fri Nov 19 20:16:12 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 19 Nov 2021 20:16:12 GMT Subject: RFR: JDK-8276447 Deprecate finalization-related methods for removal In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review. > > This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations. > > The CSR has been approved. > An automated test build+test run passes cleanly (FWIW :D ). Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6465 From lmesnik at openjdk.java.net Sat Nov 20 06:15:30 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sat, 20 Nov 2021 06:15:30 GMT Subject: RFR: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 Message-ID: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> The VMObjectAlloc jvmti event was not generated for objects created using MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance. While fixing this bug I noticed that event is not posted in the intrinsics version for many functions where it is used. Including but not limited to clone(), invoke()m allocateInstance() and allocateUninitializedArray(). There are might be other intensified functions (not analogs JVM_ENTRY versions) that allocate objects without post events. I think it is needed to implement some common way to handle this and cover it in another issue. ------------- Commit messages: - switch to collerctor. - test added. - update - fix Changes: https://git.openjdk.java.net/jdk/pull/6478/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6478&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265795 Stats: 148 lines in 4 files changed: 146 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6478/head:pull/6478 PR: https://git.openjdk.java.net/jdk/pull/6478 From sspitsyn at openjdk.java.net Sat Nov 20 13:29:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 20 Nov 2021 13:29:08 GMT Subject: RFR: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 In-Reply-To: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> References: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> Message-ID: <1xupnqHZy2mpOQLkG92XaND-T6ofJY4UvhZbh1poUng=.b6785d7b-e048-4e53-b0c9-e3cbf742c452@github.com> On Fri, 19 Nov 2021 15:32:24 GMT, Leonid Mesnik wrote: > The VMObjectAlloc jvmti event was not generated for objects created using MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance. > > While fixing this bug I noticed that event is not posted in the intrinsics version for many functions where it is used. Including but not limited to clone(), invoke()m allocateInstance() and allocateUninitializedArray(). There are might be other intensified functions (not analogs JVM_ENTRY versions) that allocate objects without post events. > > I think it is needed to implement some common way to handle this and cover it in another issue. Hi Leonid, This fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6478 From lmesnik at openjdk.java.net Sun Nov 21 00:13:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sun, 21 Nov 2021 00:13:09 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From lmesnik at openjdk.java.net Sun Nov 21 00:17:05 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sun, 21 Nov 2021 00:17:05 GMT Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> Message-ID: On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote: > 8277413: Remove unused local variables in jdk.hotspot.agent Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6329 From lmesnik at openjdk.java.net Sun Nov 21 00:21:07 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sun, 21 Nov 2021 00:21:07 GMT Subject: RFR: 8274898: Cleanup usages of StringBuffer in jdk tools modules In-Reply-To: References: Message-ID: <7FooviizG1lKmrfgzuXplwxRH3S13gXq3A8LzyZXLak=.685d673a-77a3-41d5-bd62-3d708e47867c@github.com> 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 lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5433 From dholmes at openjdk.java.net Mon Nov 22 01:46:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 22 Nov 2021 01:46:09 GMT Subject: RFR: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 In-Reply-To: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> References: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> Message-ID: On Fri, 19 Nov 2021 15:32:24 GMT, Leonid Mesnik wrote: > The VMObjectAlloc jvmti event was not generated for objects created using MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance. > > While fixing this bug I noticed that event is not posted in the intrinsics version for many functions where it is used. Including but not limited to clone(), invoke()m allocateInstance() and allocateUninitializedArray(). There are might be other intensified functions (not analogs JVM_ENTRY versions) that allocate objects without post events. > > I think it is needed to implement some common way to handle this and cover it in another issue. Hi Leonid, Functional fix looks good. A couple of minor nits below. I agree that fixing intrinsics should be a separate issue - I have to worry that the overhead of posting events can dwarf the operation itself. I would guess the intrinsic would need a short-cut to check if the event is enabled and if so drop back to non-intrinsic version. Thanks, David test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java line 49: > 47: mh.invoke("str"); > 48: > 49: if(getNumberOfAllocation() != 1) { space after 'if' please test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.cpp line 91: > 89: } > 90: > 91: } This looks spurious ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6478 From dholmes at openjdk.java.net Mon Nov 22 02:08:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 22 Nov 2021 02:08:04 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Hi Serguei, I still feel the bug here can be fixed simply by moving assertions, rather than by introducing a change in behaviour as to what error code would be returned. But I'll leave to serviceability folk to decide. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Mon Nov 22 02:08:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 22 Nov 2021 02:08:04 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> Message-ID: On Fri, 19 Nov 2021 17:04:42 GMT, Daniel D. Daugherty wrote: >> Okay. I see similar check in the `force_early_return()` function: >> >> if (state == NULL) { >> return JVMTI_ERROR_THREAD_NOT_ALIVE; >> } >> >> Would it better to replace it with this check instead? : >> >> if (java_thread->is_exiting()) { >> return JVMTI_ERROR_THREAD_NOT_ALIVE; >> } >> >> Removing this check and keep the one inside the handshake would be even better. >> >> I would also add this line for symmetry with two other cases: >> >> + MutexLocker mu(JvmtiThreadState_lock); >> SetForceEarlyReturn op(state, value, tos); > > My point is that I don't see why you added the `is_exiting()` check > since I don't see a race in that function, i.e., there's no `assert()` in > this function that you need to protect. > > As for adding the `MutexLocker mu(JvmtiThreadState_lock)`, you'll > have to analyze and justify why you would need to add that lock grab > independent of this fix. I'm not seeing a bug there, but I haven't looked > very closely. The `is_exiting` check changes the behaviour from reporting JVMTI_ERROR_THREAD_NOT_SUSPENDED to JVMTI_ERROR_THREAD_NOT_ALIVE. Arguably it is a more precise answer, but it is somewhat splitting hairs. To me it might be clearer to the developer what their logic error is if they get NOT_SUSPENDED rather than NOT_ALIVE. Either way this change is not needed to fix any known bug and the change is behaviour seems questionable. >> Dan, >> Thank you for reviewing this! >> I'm not sure, I correctly understand you here. >> Are you saying that you agree with this change? >> In fact, the thread state can not be changed (and the assert fired) after the `is_exiting()` check is made even without `JvmtiThreadState_lock` protection because it is inside of a handshake execution. > > I agree with the `is_exiting()` check addition. > > I forgot that we're executing a Handshake `doit()` function. So we have a couple > of reasons why an unsuspended target thread can't change from `!is_exiting()` > to `is_exiting()` while we are in this function. Again this introduces a more precise state check but also changes the behaviour by now reporting NOT_ALIVE instead of NOT_SUSPENDED. The assertion failure can be fixed by simply moving the assertion to after the suspension check. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From dholmes at openjdk.java.net Mon Nov 22 02:08:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 22 Nov 2021 02:08:05 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> References: <2l9gjieNV6K8UMLcGHO_CtSWzzN5Kv45pFt6_3OZ85o=.1ae38c09-bf00-45ec-ac96-838469a5f7a7@github.com> Message-ID: <9_cJhg6lSbDRvLkCZAYYpWwKYWi5gBefhTeGyvOtHGw=.8783abed-f787-4a74-85e2-da8659f9edca@github.com> On Fri, 19 Nov 2021 10:15:05 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1625: >> >>> 1623: return; /* JVMTI_ERROR_THREAD_NOT_ALIVE (default) */ >>> 1624: } >>> 1625: assert(_state->get_thread() == java_thread, "Must be"); >> >> The `assert()` on L1625 is subject to the same race as the original site. >> This `is_exiting()` check is made under the protection of the >> `JvmtiThreadState_lock` so it is sufficient to protect that `assert()`. > > Okay, thanks! Same comment as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From lmesnik at openjdk.java.net Mon Nov 22 04:23:00 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 22 Nov 2021 04:23:00 GMT Subject: RFR: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 [v2] In-Reply-To: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> References: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> Message-ID: > The VMObjectAlloc jvmti event was not generated for objects created using MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance. > > While fixing this bug I noticed that event is not posted in the intrinsics version for many functions where it is used. Including but not limited to clone(), invoke()m allocateInstance() and allocateUninitializedArray(). There are might be other intensified functions (not analogs JVM_ENTRY versions) that allocate objects without post events. > > I think it is needed to implement some common way to handle this and cover it in another issue. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6478/files - new: https://git.openjdk.java.net/jdk/pull/6478/files/e160dbe3..b37ee052 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6478&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6478&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6478/head:pull/6478 PR: https://git.openjdk.java.net/jdk/pull/6478 From lmesnik at openjdk.java.net Mon Nov 22 04:23:01 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 22 Nov 2021 04:23:01 GMT Subject: RFR: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 [v2] In-Reply-To: References: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> Message-ID: On Mon, 22 Nov 2021 01:38:47 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed > > test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java line 49: > >> 47: mh.invoke("str"); >> 48: >> 49: if(getNumberOfAllocation() != 1) { > > space after 'if' please fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/6478 From shade at openjdk.java.net Mon Nov 22 09:21:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Nov 2021 09:21:41 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v4] In-Reply-To: References: 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` Aleksey Shipilev 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: - Fix a comment - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - More reviews - Review feedback - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - Initial work: runs async-profiler successfully ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5848/files - new: https://git.openjdk.java.net/jdk/pull/5848/files/68ef4b63..bc4ba33b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=02-03 Stats: 44745 lines in 800 files changed: 32663 ins; 5661 del; 6421 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 sspitsyn at openjdk.java.net Mon Nov 22 09:26:03 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 22 Nov 2021 09:26:03 GMT Subject: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn wrote: >> The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL Hi David, Thank you for looking at this and your comments. Exiting thread should not be in suspended state. Also, I'm pretty sure that the THREAD_NOT_ALIVE error code should normally take priority. So, I prefer current fix over moving the assert. But I kind of understand you concern. Thank you for sharing it! Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From tschatzl at openjdk.java.net Mon Nov 22 10:02:05 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 22 Nov 2021 10:02:05 GMT Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> Message-ID: On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote: > 8277413: Remove unused local variables in jdk.hotspot.agent Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6329 From sspitsyn at openjdk.java.net Mon Nov 22 10:36:07 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 22 Nov 2021 10:36:07 GMT Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> Message-ID: On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote: > 8277413: Remove unused local variables in jdk.hotspot.agent Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6329 From sspitsyn at openjdk.java.net Mon Nov 22 10:51:13 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 22 Nov 2021 10:51:13 GMT Subject: Integrated: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 22:21:33 GMT, Serguei Spitsyn wrote: > The test fails when the target JavaThread has is_exiting() status. In such a case the JvmtiExport::cleanup_thread(this) has already made a clean up of its jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is 0xbabababababababa. > The fix is to add a check for is_exiting() status into handshake closure do_thread() early. > There following handshake closures are fixed by this update: > - UpdateForPopTopFrameClosure > - SetForceEarlyReturn > - SetFramePopClosure This pull request has now been integrated. Changeset: 32839ba0 Author: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/32839ba012f0a0a66e249cd8d12b94499d82ec0a Stats: 22 lines in 2 files changed: 10 ins; 6 del; 6 mod 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Reviewed-by: mdoerr, lmesnik, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/6440 From eosterlund at openjdk.java.net Mon Nov 22 14:03:34 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 22 Nov 2021 14:03:34 GMT Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper Message-ID: The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used. ------------- Commit messages: - 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper Changes: https://git.openjdk.java.net/jdk/pull/6501/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276696 Stats: 70 lines in 15 files changed: 35 ins; 11 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/6501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6501/head:pull/6501 PR: https://git.openjdk.java.net/jdk/pull/6501 From lmesnik at openjdk.java.net Mon Nov 22 17:14:29 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 22 Nov 2021 17:14:29 GMT Subject: Integrated: 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 In-Reply-To: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> References: <_uX5GXu4fEzqseTEdOTcEH0HKiwQ8jeccft8kd5_Hcg=.3c1b3d8b-63f0-4d1b-a238-a10e86dd012c@github.com> Message-ID: On Fri, 19 Nov 2021 15:32:24 GMT, Leonid Mesnik wrote: > The VMObjectAlloc jvmti event was not generated for objects created using MethodHanldle. The fix adds posting of the event into Unsafe_AllocateInstance. > > While fixing this bug I noticed that event is not posted in the intrinsics version for many functions where it is used. Including but not limited to clone(), invoke()m allocateInstance() and allocateUninitializedArray(). There are might be other intensified functions (not analogs JVM_ENTRY versions) that allocate objects without post events. > > I think it is needed to implement some common way to handle this and cover it in another issue. This pull request has now been integrated. Changeset: 33e2a518 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/33e2a518ebcd50e76c559512539fd7c864fd2407 Stats: 148 lines in 4 files changed: 146 ins; 2 del; 0 mod 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6478 From lmesnik at openjdk.java.net Tue Nov 23 06:58:40 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 23 Nov 2021 06:58:40 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" Message-ID: The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. The deletion of agentThread variable should be synced with the termination of the agent thread. ------------- Commit messages: - merge - fix Changes: https://git.openjdk.java.net/jdk/pull/6515/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6515&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264605 Stats: 27 lines in 2 files changed: 5 ins; 15 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6515.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6515/head:pull/6515 PR: https://git.openjdk.java.net/jdk/pull/6515 From dholmes at openjdk.java.net Tue Nov 23 08:06:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 23 Nov 2021 08:06:07 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote: > The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. > > The deletion of agentThread variable should be synced with the termination of the agent thread. Hi Leonid, I don't think this is sufficient. You have moved the cleanup of the agentThread under the protection of the rawMonitor for termination, but unless the initialization of agentThread is also protected by the rawMonitor then you still have a problem AFAICS. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From anton.haubner at outlook.de Tue Nov 23 09:25:41 2021 From: anton.haubner at outlook.de (Anton W. Haubner) Date: Tue, 23 Nov 2021 10:25:41 +0100 Subject: JDWP features hidden under JDI Message-ID: Hello! I am working on a new kind of debugger which extracts information about the state of Java programs through the JDI to build RDF knowledge graphs. While working on the project, I noticed that there is certain information about the program state that is accessible through JDWP, but which is hidden by the JDI interfaces (see below for examples). I am curious, whether this was done to simplify the interface, or if there is a deeper reason behind this, e.g. because the information in question is unreliable etc. If there is no such reason, I might try to modify the JDI reference implementation to provide this information to me. *First Example: Retrieving Objects by ID* The ObjectReference JDI interface does allow to retrieve the unique id assigned to an object by the JDWP agent. However, it seems it is not possible to construct an ObjectReference from such an id. That is, one can not quickly look up an object by its id, but has to search through all objects to find it again. Looking at the JDWP specification, it seems that the underlying JDWP protocol does support looking up objects using just their id: https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_ObjectReference The reference implementation of the `ObjectReference` interface also seems to only require this id to retrieve all required information: https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java#L109 /My question now is:/ Is there a specific reason that there is no public factory method to construct an ObjectReference from an object id? Or would it be "safe" to create a custom `ObjectReference` implementation that allows this, as long as it deals with the `INVALID_OBJECT` error case of JDWP? *Second Example: Variable Locations* The JDWP `VariableTable` command reply does contain the code index of variables. Nevertheless, it is neither possible to retrieve the code index of a variable through the `LocalVariable` JDI interface, nor through the `Method` interface. Meanwhile, internally, the `LocalVariable` reference implementation does seem to store the scope of a variable: https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java#L56 The Eclipse JDI implementation also stores the plain code index value: https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/LocalVariableImpl.java#n63 Is there a specific reason, why this location information is not exposed in the public interface? Thank you very much for reading my questions. Can you help me to answer them? Best regards, Anton Haubner -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From pliden at openjdk.java.net Tue Nov 23 09:45:10 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 23 Nov 2021 09:45:10 GMT Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund wrote: > The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used. Looks good. ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6501 From stefank at openjdk.java.net Tue Nov 23 09:52:06 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 23 Nov 2021 09:52:06 GMT Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund wrote: > The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6501 From david.holmes at oracle.com Tue Nov 23 10:18:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Nov 2021 20:18:37 +1000 Subject: JDWP features hidden under JDI In-Reply-To: References: Message-ID: <79fbd2da-5bb4-7e56-1da7-4f51f821ec4e@oracle.com> Hi Anton, There may be someone who recalls this detail of ancient history but it is ancient. :) As a low-level protocol JDWP exposes a lot of things. But then the higher-level API's, like the original JVM DI, and its replacement JVM TI, provide a different level of abstraction and need not expose as much low-level detail (but may need that lower-level information to implement their own APIs). Then JDI is a higher-level API again. Answering "why" 20+ years later is not an easy thing. :) Cheers, David On 23/11/2021 7:25 pm, Anton W. Haubner wrote: > Hello! > > I am working on a new kind of debugger which extracts information about the > state of Java programs through the JDI to build RDF knowledge graphs. > > While working on the project, I noticed that there is certain > information about > the program state that is accessible through JDWP, but which is hidden > by the > JDI interfaces (see below for examples). > > I am curious, whether this was done to simplify the interface, or if > there is > a deeper reason behind this, e.g. because the information in question is > unreliable etc. > If there is no such reason, I might try to modify the JDI reference > implementation to provide this information to me. > > *First Example: Retrieving Objects by ID* > > The ObjectReference JDI interface does allow to retrieve the unique id > assigned to > an object by the JDWP agent. > > However, it seems it is not possible to construct an ObjectReference > from such > an id. That is, one can not quickly look up an object by its id, but has to > search through all objects to find it again. > > Looking at the JDWP specification, it seems that the underlying JDWP > protocol > does support looking up objects using just their id: > https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_ObjectReference > > The reference implementation of the `ObjectReference` interface also > seems to > only require this id to retrieve all required information: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java#L109 > > /My question now is:/ > Is there a specific reason that there is no public factory method to > construct > an ObjectReference from an object id? > Or would it be "safe" to create a custom `ObjectReference` > implementation that > allows this, as long as it deals with the `INVALID_OBJECT` error case of > JDWP? > > *Second Example: Variable Locations* > > The JDWP `VariableTable` command reply does contain the code index of > variables. > Nevertheless, it is neither possible to retrieve the code index of a > variable > through the `LocalVariable` JDI interface, nor through the `Method` > interface. > > Meanwhile, internally, the `LocalVariable` reference implementation does > seem > to store the scope of a variable: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java#L56 > > The Eclipse JDI implementation also stores the plain code index value: > https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/LocalVariableImpl.java#n63 > > Is there a specific reason, why this location information is not exposed > in the > public interface? > > > > > Thank you very much for reading my questions. > Can you help me to answer them? > > Best regards, > > Anton Haubner > From duke at openjdk.java.net Tue Nov 23 12:36:13 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 23 Nov 2021 12:36:13 GMT Subject: Integrated: 8277413: Remove unused local variables in jdk.hotspot.agent In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com> Message-ID: <2dDByjhg7f6KvM1CE8VrnwZwfKAQc-gmgob8adjXqRw=.fd805610-4493-4840-99b4-1a6d9d5102ef@github.com> On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov wrote: > 8277413: Remove unused local variables in jdk.hotspot.agent This pull request has now been integrated. Changeset: 66eaf652 Author: Andrey Turbanov Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/66eaf6526126eb27c18acc64c2bb0791142815c9 Stats: 26 lines in 8 files changed: 0 ins; 14 del; 12 mod 8277413: Remove unused local variables in jdk.hotspot.agent Reviewed-by: lmesnik, tschatzl, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6329 From eosterlund at openjdk.java.net Tue Nov 23 13:42:06 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 23 Nov 2021 13:42:06 GMT Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper In-Reply-To: References: Message-ID: <8246XgMZ_pumK-BgCx9osG0N9jvJxNGmcJVw8s_0oqo=.d723b7d4-ac0e-4897-af9f-65524377ab87@github.com> On Tue, 23 Nov 2021 09:42:10 GMT, Per Liden wrote: >> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used. > > Looks good. Thanks for the reviews, @pliden and @stefank! ------------- PR: https://git.openjdk.java.net/jdk/pull/6501 From eosterlund at openjdk.java.net Tue Nov 23 14:38:15 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 23 Nov 2021 14:38:15 GMT Subject: Integrated: 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund wrote: > The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used. This pull request has now been integrated. Changeset: f4dc03ea Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634 Stats: 70 lines in 15 files changed: 35 ins; 11 del; 24 mod 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper Reviewed-by: pliden, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/6501 From lmesnik at openjdk.java.net Tue Nov 23 16:04:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 23 Nov 2021 16:04:09 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote: > The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. > > The deletion of agentThread variable should be synced with the termination of the agent thread. The new thread is started in nsk_jvmti_runAgentThread which is executed under monitors also as well as nsk_jvmti_resetAgentData. Could you please point exact location which is not protected? Seems all thread_state changes and agentThread changes are protected. ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From cjplummer at openjdk.java.net Tue Nov 23 18:57:03 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 23 Nov 2021 18:57:03 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [v3] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 04:03:06 GMT, Leonid Mesnik wrote: >> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. >> This fix also prints references to inspected class. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > force GC to clean weak references Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Tue Nov 23 19:31:19 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 23 Nov 2021 19:31:19 GMT Subject: RFR: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416 [v4] In-Reply-To: References: Message-ID: <33Ju8qXS33hZvvCXLiayHrYz9bZLuH_HYg47nJ5pwcI=.3052bb52-492e-41db-9cfd-0ec03d7ac9f8@github.com> > The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. > This fix also prints references to inspected class. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into 8265796 - force GC to clean weak references - updated - fix ------------- Changes: https://git.openjdk.java.net/jdk/pull/6402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6402&range=03 Stats: 18 lines in 3 files changed: 13 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6402/head:pull/6402 PR: https://git.openjdk.java.net/jdk/pull/6402 From lmesnik at openjdk.java.net Tue Nov 23 19:31:20 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 23 Nov 2021 19:31:20 GMT Subject: Integrated: 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416 In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:03:46 GMT, Leonid Mesnik wrote: > The nsk.share.jdi.TestClass1 is used via reflection. The reflective call creates MethodHandle and one more reference to TestClass1. So the number of expected references should be incremented. Thanks to @plummercj and @mlchung for the investigation. > This fix also prints references to inspected class. This pull request has now been integrated. Changeset: 7cb56a23 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/7cb56a230dbd52935ae48fe44b4192ae3b4d7adb Stats: 18 lines in 3 files changed: 13 ins; 2 del; 3 mod 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416 Reviewed-by: cjplummer, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/6402 From sspitsyn at openjdk.java.net Tue Nov 23 22:44:07 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 23 Nov 2021 22:44:07 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote: > The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. > > The deletion of agentThread variable should be synced with the termination of the agent thread. Hi Leonid, It looks good to me. I see the initialization of agentThread is also protected with the data.monitor. This code is a little bit ugly, so it is not clear that startAgentThreadWrapper is executed under rawMonitor protection. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6515 From chris.plummer at oracle.com Tue Nov 23 23:30:43 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 23 Nov 2021 15:30:43 -0800 Subject: JDWP features hidden under JDI In-Reply-To: References: Message-ID: <82a53dd6-149a-3857-c275-7c921e750c81@oracle.com> Hi Anton, > Looking at the JDWP specification, it seems that the underlying JDWP > protocol > does support looking up objects using just their id: Maybe this is just a terminology issue, but I'm not sure what you mean by "lookup". JDWP doesn't lookup ObjectIDs. It returns them any place where there is an object reference. For example, if a field of a java object or stack local refer to a java object, it will be represented by an ObjectID. At the JDI level, an ObjectReference tracks the underlying JDWP ObjectID. So in this sense there are two different ways to represent a java object; the ObjectReference or the underlying JDWP ObjectID. You've pointed out that you can map from an ObjectReference to an ObjectID, but not the other way around. There is not a 1-to-1 relationship between ObjectReference instances and ObjectIDs. You can have multiple ObjectReference objects that reference the same ObjectID. So there is no way to map from an ObjectID to an ObjectReference (since there can be more than one). > /My question now is:/ > Is there a specific reason that there is no public factory method to > construct > an ObjectReference from an object id? > Or would it be "safe" to create a custom `ObjectReference` > implementation that > allows this, as long as it deals with the `INVALID_OBJECT` error case > of JDWP? I think the main issue would be validation. Currently the JDI implementation creates ObjectReference instances based on the ObjectID it got from JDWP. You're proposing that the user supply the ObjectID. The assumption is that it came from another ObjectReference so should be valid, but not only is it possible that the ObjectID could have been fabricated, but it also could have been valid at one point but no longer is (the referred to object may have been GC'd). So the question about safety here is somewhat relative. I assume it can be done and should for the most part work, but you could possibly run into issues in some error conditions. One question I have is why do you want to do this? It sounds like you want to cache or store ObjectIDs instead of ObjectReferences, but later want to map the ObjectID back to an ObjectReference. Why not just store the ObjectReference? > Is there a specific reason, why this location information is not > exposed in the > public interface? Why do you want the slot? If it is so you can later map the slot to a LocalVariable, you'll run into issues if more than one LocalVariable can use that slot. This is why LocalVariables have scopeStart and scopeEnd fields. You would need to also specify a bytecode index when doing the lookup if there is more than one LocalVariable that maps to the same slot. cheers, Chris On 11/23/21 1:25 AM, Anton W. Haubner wrote: > > Hello! > > I am working on a new kind of debugger which extracts information > about the > state of Java programs through the JDI to build RDF knowledge graphs. > > While working on the project, I noticed that there is certain > information about > the program state that is accessible through JDWP, but which is hidden > by the > JDI interfaces (see below for examples). > > I am curious, whether this was done to simplify the interface, or if > there is > a deeper reason behind this, e.g. because the information in question is > unreliable etc. > If there is no such reason, I might try to modify the JDI reference > implementation to provide this information to me. > > *First Example: Retrieving Objects by ID* > > The ObjectReference JDI interface does allow to retrieve the unique id > assigned to > an object by the JDWP agent. > > However, it seems it is not possible to construct an ObjectReference > from such > an id. That is, one can not quickly look up an object by its id, but > has to > search through all objects to find it again. > > Looking at the JDWP specification, it seems that the underlying JDWP > protocol > does support looking up objects using just their id: > https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_ObjectReference > > The reference implementation of the `ObjectReference` interface also > seems to > only require this id to retrieve all required information: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java#L109 > > /My question now is:/ > Is there a specific reason that there is no public factory method to > construct > an ObjectReference from an object id? > Or would it be "safe" to create a custom `ObjectReference` > implementation that > allows this, as long as it deals with the `INVALID_OBJECT` error case > of JDWP? > > *Second Example: Variable Locations* > > The JDWP `VariableTable` command reply does contain the code index of > variables. > Nevertheless, it is neither possible to retrieve the code index of a > variable > through the `LocalVariable` JDI interface, nor through the `Method` > interface. > > Meanwhile, internally, the `LocalVariable` reference implementation > does seem > to store the scope of a variable: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java#L56 > > The Eclipse JDI implementation also stores the plain code index value: > https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/LocalVariableImpl.java#n63 > > Is there a specific reason, why this location information is not > exposed in the > public interface? > > > > > Thank you very much for reading my questions. > Can you help me to answer them? > > Best regards, > > Anton Haubner > From serguei.spitsyn at oracle.com Wed Nov 24 01:29:16 2021 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Wed, 24 Nov 2021 01:29:16 +0000 Subject: JDWP features hidden under JDI In-Reply-To: References: Message-ID: <69E1653B-1526-46CB-B119-31CEF492CE09@oracle.com> Hi Anton, Thank you for the questions. I don?t know the history well enough, so will try to guess a little bit. Please, see my attempts to answer your questions inlined below. From: serviceability-dev on behalf of "Anton W. Haubner" Date: Tuesday, November 23, 2021 at 1:25 AM To: Cc: Eduard Kamburjan Subject: JDWP features hidden under JDI Hello! I am working on a new kind of debugger which extracts information about the state of Java programs through the JDI to build RDF knowledge graphs. The project you are working on looks interesting. While working on the project, I noticed that there is certain information about the program state that is accessible through JDWP, but which is hidden by the JDI interfaces (see below for examples). I am curious, whether this was done to simplify the interface, or if there is a deeper reason behind this, e.g. because the information in question is unreliable etc. If there is no such reason, I might try to modify the JDI reference implementation to provide this information to me. First Example: Retrieving Objects by ID The ObjectReference JDI interface does allow to retrieve the unique id assigned to an object by the JDWP agent. However, it seems it is not possible to construct an ObjectReference from such an id. That is, one can not quickly look up an object by its id, but has to search through all objects to find it again. Looking at the JDWP specification, it seems that the underlying JDWP protocol does support looking up objects using just their id: https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_ObjectReference The reference implementation of the `ObjectReference` interface also seems to only require this id to retrieve all required information: https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java#L109 My question now is: Is there a specific reason that there is no public factory method to construct an ObjectReference from an object id? Or would it be "safe" to create a custom `ObjectReference` implementation that allows this, as long as it deals with the `INVALID_OBJECT` error case of JDWP? My understanding is that the JDI just provides a way to store/cache the ObjectReference uniqueID() value. I feel that I understand why you consider custom `ObjectReference` implementation API to be useful. But as Chris already answered in order to implement it we need a validation of such uniqueID values. The JDWP protocol ObjectReference#ReferenceType command looks like a good candidate to provide this verification. But there still is a question if this custom API is really needed and why do not cache ObjectReference?s instead. My guess is that you want it to save on memory overhead. Is it true? If so, is it worth the effort and extra complexity? Second Example: Variable Locations The JDWP `VariableTable` command reply does contain the code index of variables. Nevertheless, it is neither possible to retrieve the code index of a variable through the `LocalVariable` JDI interface, nor through the `Method` interface. Meanwhile, internally, the `LocalVariable` reference implementation does seem to store the scope of a variable: https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java#L56 The Eclipse JDI implementation also stores the plain code index value: https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/LocalVariableImpl.java#n63 Is there a specific reason, why this location information is not exposed in the public interface? My guess is that nobody was asking for this before or nobody seen reasonable use cases for it. It should not be difficult to add an API to provide this info. But again, the question is if your use cases can justify extra complexity. Thanks, Serguei Thank you very much for reading my questions. Can you help me to answer them? Best regards, Anton Haubner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.java.net Wed Nov 24 02:20:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 24 Nov 2021 02:20:02 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote: > The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. > > The deletion of agentThread variable should be synced with the termination of the agent thread. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From dholmes at openjdk.java.net Wed Nov 24 02:20:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 24 Nov 2021 02:20:03 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 16:01:27 GMT, Leonid Mesnik wrote: >> The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. >> >> The deletion of agentThread variable should be synced with the termination of the agent thread. > > The new thread is started in nsk_jvmti_runAgentThread which is executed under monitors also as well as nsk_jvmti_resetAgentData. > Could you please point exact location which is not protected? Seems all thread_state changes and agentThread changes are protected. Sorry @lmesnik I missed the higher-level use of the monitor when starting the thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From lmesnik at openjdk.java.net Wed Nov 24 20:14:12 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 24 Nov 2021 20:14:12 GMT Subject: RFR: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 02:16:29 GMT, David Holmes wrote: >> The new thread is started in nsk_jvmti_runAgentThread which is executed under monitors also as well as nsk_jvmti_resetAgentData. >> Could you please point exact location which is not protected? Seems all thread_state changes and agentThread changes are protected. > > Sorry @lmesnik I missed the higher-level use of the monitor when starting the thread. @dholmes-ora, @sspitsyn - Thank you for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From lmesnik at openjdk.java.net Wed Nov 24 20:14:13 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 24 Nov 2021 20:14:13 GMT Subject: Integrated: 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 06:49:47 GMT, Leonid Mesnik wrote: > The agentThread variable might have been set by the new agentThread iteration and then deleted in the wrapper from the previous iteration. > > The deletion of agentThread variable should be synced with the termination of the agent thread. This pull request has now been integrated. Changeset: 96fe1d0d Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/96fe1d0d4d95d87950ff2ecec570a927d831746e Stats: 27 lines in 2 files changed: 5 ins; 15 del; 7 mod 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6515 From anton.haubner at outlook.de Wed Nov 24 21:05:18 2021 From: anton.haubner at outlook.de (Anton W. Haubner) Date: Wed, 24 Nov 2021 22:05:18 +0100 Subject: JDWP features hidden under JDI In-Reply-To: <69E1653B-1526-46CB-B119-31CEF492CE09@oracle.com> References: <69E1653B-1526-46CB-B119-31CEF492CE09@oracle.com> Message-ID: Hi David, Chris and Serguei, thank you all for your quick answers and recommendations! > Chris: Maybe this is just a terminology issue, but I'm not sure what you mean by "lookup" > Chris: It sounds like you want to cache or store ObjectIDs instead of ObjectReferences, but later want to map the ObjectID back to an ObjectReference. You are exactly right. Basically I would need to obtain some ObjectReference object that references a specific object id. To give more context: I am storing a (partial) representation of the Java objects of the current program state in RDF format. This RDF graph is then further processed by external tooling. For example, the objects stored in it might be filtered according to some criteria. After that filtering, I might need to retrieve further information about a Java object through the JDI, given only the object id I have from the RDF graph. > Chris: Why not just store the ObjectReference? Yes, keeping a HashMap or something similar that maps object ids to cached ObjectReferences could work. > Serguei: My guess is that you want it to save on memory overhead. Is it true? True. I was unsure how well this scales for larger programs since I need to store an ObjectReference for every object in the JVM state. On the other hand, I imagine the JDWP agent internally implements some map structure anyway since it needs to keep track of the object IDs. > Serguei: If so, is it worth the effort and extra complexity? I guess I will need to give the caching solution a try and experiment a bit with larger programs. > Chris: I think the main issue would be validation True. By construction of the RDF graph, I probably will not run into object Ids that are not assigned to an object. Especially since I am not continuing execution while processing object ids. In any case, as Serguei pointed out, it should be possible to validate ids via the JDWP or at least deal with error cases. Regarding the variable locations / code indices: > Chris: Why do you want the slot? I want to obtain the source code location of variables and store them in my RDF graph, too. In the end, I want to be able to ask the RDF graph, in which variables an object is stored, and where in the source code those variables are located. If multiple variables share the same line location, that would not be an issue. Ok, so for now, I conclude: 1. I might be able to get away with a caching solution for the object IDs and ObjectReferences, but I have to test this with some larger use cases. 2. Variable locations are stored internally and some might point to the same source code line. To access them I would definitely need to adapt the JDI implementation, though. ? (Alternatively, I could use some external tool which gives me the AST of the source code with annotated locations. Then I could extract the variable locations from there using the variable name + method name + class name.) Again, thank you all :) Best regards, Anton On 11/24/21 02:29, Serguei Spitsyn wrote: > > Hi Anton, > > Thank you for the questions. > > I don?t know the history well enough, so will try to guess a little bit. > > Please, see my attempts to answer your questions inlined below. > > *From: *serviceability-dev > on behalf of "Anton W. Haubner" > *Date: *Tuesday, November 23, 2021 at 1:25 AM > *To: * > *Cc: *Eduard Kamburjan > *Subject: *JDWP features hidden under JDI > > Hello! > > I am working on a new kind of debugger which extracts information > about the > state of Java programs through the JDI to build RDF knowledge graphs. > > ?????The project you are working on looks interesting. > > While working on the project, I noticed that there is certain > information about > the program state that is accessible through JDWP, but which is hidden > by the > JDI interfaces (see below for examples). > > I am curious, whether this was done to simplify the interface, or if > there is > a deeper reason behind this, e.g. because the information in question is > unreliable etc. > If there is no such reason, I might try to modify the JDI reference > implementation to provide this information to me. > > *First Example: Retrieving Objects by ID* > > The ObjectReference JDI interface does allow to retrieve the unique id > assigned to > an object by the JDWP agent. > > However, it seems it is not possible to construct an ObjectReference > from such > an id. That is, one can not quickly look up an object by its id, but > has to > search through all objects to find it again. > > Looking at the JDWP specification, it seems that the underlying JDWP > protocol > does support looking up objects using just their id: > https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_ObjectReference > > The reference implementation of the `ObjectReference` interface also > seems to > only require this id to retrieve all required information: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java#L109 > > /My question now is:/ > Is there a specific reason that there is no public factory method to > construct > an ObjectReference from an object id? > Or would it be "safe" to create a custom `ObjectReference` > implementation that > allows this, as long as it deals with the `INVALID_OBJECT` error case > of JDWP? > > ?? My understanding is that the JDI just provides a way to store/cache > the ObjectReference uniqueID() value. > ?? I feel that I understand why you consider custom `ObjectReference` > implementation API to be useful. > ?? But as Chris already answered in order to implement it we need a > validation of such uniqueID values. > ?? The JDWP protocol ObjectReference#ReferenceType command looks like > a good candidate to provide this verification. > > ?? But there still is a question if this custom API is really needed > and why do not cache ObjectReference?s instead. > ?? My guess is that you want it to save on memory overhead. Is it true? > ?? If so, is it worth the effort and extra complexity? > > > *Second Example: Variable Locations* > > The JDWP `VariableTable` command reply does contain the code index of > variables. > Nevertheless, it is neither possible to retrieve the code index of a > variable > through the `LocalVariable` JDI interface, nor through the `Method` > interface. > > Meanwhile, internally, the `LocalVariable` reference implementation > does seem > to store the scope of a variable: > https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java#L56 > > The Eclipse JDI implementation also stores the plain code index value: > https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/tree/org.eclipse.jdt.debug/jdi/org/eclipse/jdi/internal/LocalVariableImpl.java#n63 > > Is there a specific reason, why this location information is not > exposed in the > public interface? > > ?? My guess is that nobody was asking for this before or nobody seen > reasonable use cases for it. > ?? It should not be difficult to add an API to provide this info. > ?? But again, the question is if your use cases can justify extra > complexity. > > ?? Thanks, > ?? Serguei > > > Thank you very much for reading my questions. > Can you help me to answer them? > > Best regards, > > Anton Haubner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcubed at openjdk.java.net Wed Nov 24 22:21:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 24 Nov 2021 22:21:24 GMT Subject: RFR: 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java Message-ID: A couple of trivial ProblemListings: JDK-8277811 ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java JDK-8277813 ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java ------------- Commit messages: - 8277813: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java - 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java Changes: https://git.openjdk.java.net/jdk/pull/6547/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6547&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277811 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6547.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6547/head:pull/6547 PR: https://git.openjdk.java.net/jdk/pull/6547 From dholmes at openjdk.java.net Wed Nov 24 22:21:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 24 Nov 2021 22:21:24 GMT Subject: RFR: 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 22:03:29 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > > JDK-8277811 ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java > JDK-8277813 ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6547 From dcubed at openjdk.java.net Wed Nov 24 22:30:09 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 24 Nov 2021 22:30:09 GMT Subject: RFR: 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 22:08:31 GMT, David Holmes wrote: >> A couple of trivial ProblemListings: >> >> JDK-8277811 ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java >> JDK-8277813 ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/6547 From dcubed at openjdk.java.net Wed Nov 24 22:30:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 24 Nov 2021 22:30:10 GMT Subject: Integrated: 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 22:03:29 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > > JDK-8277811 ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java > JDK-8277813 ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java This pull request has now been integrated. Changeset: 26472bd3 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/26472bd3bd8788b0839e2871ed220e438fb6d608 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java 8277813: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/6547 From lkorinth at openjdk.java.net Fri Nov 26 12:35:03 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 26 Nov 2021 12:35:03 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 09:36:38 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: > > review updates This comment will keep this pull request alive a bit longer. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From duke at openjdk.java.net Sat Nov 27 10:01:07 2021 From: duke at openjdk.java.net (duke) Date: Sat, 27 Nov 2021 10:01:07 GMT Subject: Withdrawn: 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5625 From cushon at openjdk.java.net Mon Nov 29 21:47:16 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Mon, 29 Nov 2021 21:47:16 GMT Subject: RFR: 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" Message-ID: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> This change fixes `vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623). [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623) causes javac to omit a synthetic field from inner classes that do not reference their enclosing instance. The test was specifically checking for the presence of the synthetic field. To fix the test, this change adds an explicit reference to the enclosing instance of an inner class. ------------- Commit messages: - vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" Changes: https://git.openjdk.java.net/jdk/pull/6601/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6601&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277803 Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6601.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6601/head:pull/6601 PR: https://git.openjdk.java.net/jdk/pull/6601 From dholmes at openjdk.java.net Mon Nov 29 22:57:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 29 Nov 2021 22:57:04 GMT Subject: RFR: 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" In-Reply-To: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> References: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> Message-ID: <1Kj_YwWkerPqQU9u3rUiK1LqfXt-z2LjkOiO70okkM4=.b59598fe-7950-4bf6-8a51-27f9032bdc35@github.com> On Mon, 29 Nov 2021 21:38:14 GMT, Liam Miller-Cushon wrote: > This change fixes `vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623). > > [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623) causes javac to omit a synthetic field from inner classes that do not reference their enclosing instance. The test was specifically checking for the presence of the synthetic field. To fix the test, this change adds an explicit reference to the enclosing instance of an inner class. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6601 From cjplummer at openjdk.java.net Mon Nov 29 23:25:14 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 29 Nov 2021 23:25:14 GMT Subject: RFR: 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" In-Reply-To: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> References: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> Message-ID: On Mon, 29 Nov 2021 21:38:14 GMT, Liam Miller-Cushon wrote: > This change fixes `vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623). > > [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623) causes javac to omit a synthetic field from inner classes that do not reference their enclosing instance. The test was specifically checking for the presence of the synthetic field. To fix the test, this change adds an explicit reference to the enclosing instance of an inner class. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6601 From sspitsyn at openjdk.java.net Mon Nov 29 23:25:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 29 Nov 2021 23:25:15 GMT Subject: RFR: 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" In-Reply-To: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> References: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> Message-ID: On Mon, 29 Nov 2021 21:38:14 GMT, Liam Miller-Cushon wrote: > This change fixes `vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623). > > [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623) causes javac to omit a synthetic field from inner classes that do not reference their enclosing instance. The test was specifically checking for the presence of the synthetic field. To fix the test, this change adds an explicit reference to the enclosing instance of an inner class. Hi Liam, It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6601 From cushon at openjdk.java.net Tue Nov 30 01:38:09 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Tue, 30 Nov 2021 01:38:09 GMT Subject: Integrated: 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" In-Reply-To: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> References: <3erghp1iyKqS0KP4K7jeJ4Zu872qnNC7e0_V8fayhAw=.dace8f08-c367-418f-8160-5b00a231dd06@github.com> Message-ID: <2mh7AvIVH7FsibvmekICggkFV4wK-Q40LnywEwPMwuk=.fa0ec642-dcff-4d94-8a81-8364edeb8265@github.com> On Mon, 29 Nov 2021 21:38:14 GMT, Liam Miller-Cushon wrote: > This change fixes `vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001` after [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623). > > [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8271623) causes javac to omit a synthetic field from inner classes that do not reference their enclosing instance. The test was specifically checking for the presence of the synthetic field. To fix the test, this change adds an explicit reference to the enclosing instance of an inner class. This pull request has now been integrated. Changeset: 27299eaa Author: Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk/commit/27299eaa98fd2d608a6cecfbf2b1a2a177bd5e9a Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod 8277803: vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001 fails with "Synthetic fields not found" Reviewed-by: dholmes, cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6601 From coleenp at openjdk.java.net Tue Nov 30 02:45:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 30 Nov 2021 02:45:34 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark Message-ID: This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. Testing tier1-6 in progress. ------------- Commit messages: - 8265150: AsyncGetCallTrace crashes on ResourceMark Changes: https://git.openjdk.java.net/jdk/pull/6606/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6606&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265150 Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6606.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6606/head:pull/6606 PR: https://git.openjdk.java.net/jdk/pull/6606 From dholmes at openjdk.java.net Tue Nov 30 04:43:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 30 Nov 2021 04:43:06 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. Hi Coleen, This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :( Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6606 From stuefe at openjdk.java.net Tue Nov 30 06:07:02 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 30 Nov 2021 06:07:02 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6606 From eosterlund at openjdk.java.net Tue Nov 30 06:07:02 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 30 Nov 2021 06:07:02 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6606 From stuefe at openjdk.java.net Tue Nov 30 06:07:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 30 Nov 2021 06:07:03 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 04:39:58 GMT, David Holmes wrote: > Hi Coleen, > > This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :( > > Thanks, David Does AsyncGetCallTrace get triggered asynchronously via signal? ------------- PR: https://git.openjdk.java.net/jdk/pull/6606 From dholmes at openjdk.java.net Tue Nov 30 06:24:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 30 Nov 2021 06:24:02 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 06:02:08 GMT, Thomas Stuefe wrote: > > Hi Coleen, > > This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :( > > Thanks, David > > Does AsyncGetCallTrace get triggered asynchronously via signal? Yes: ```V [libjvm.so+0x986023] AsyncGetCallTrace+0x1e5 C [libasyncProfiler.so+0x89b4] Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int)+0xd4 C [libasyncProfiler.so+0x9242] Profiler::recordSample(void*, unsigned long long, int, Event*)+0xd2 C [libasyncProfiler.so+0x34f2c] PerfEvents::signalHandler(int, siginfo_t*, void*)+0x8c ------------- PR: https://git.openjdk.java.net/jdk/pull/6606 From stuefe at openjdk.java.net Tue Nov 30 07:21:06 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 30 Nov 2021 07:21:06 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. > > > Hi Coleen, > > > This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :( > > > Thanks, David > > > > > > Does AsyncGetCallTrace get triggered asynchronously via signal? > > Yes: > > ```v > C [libasyncProfiler.so+0x89b4] Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int)+0xd4 > C [libasyncProfiler.so+0x9242] Profiler::recordSample(void*, unsigned long long, int, Event*)+0xd2 > C [libasyncProfiler.so+0x34f2c] PerfEvents::signalHandler(int, siginfo_t*, void*)+0x8c > ``` What you could do is keep (on demand only) a secondary resource area per thread. On entering a context that may have been called by a signal handler, and with the current resource area in an unknown state, swap the current resource area pointer in Thread with that prepared secondary resource area, and upon leaving swap back. That way you never touch the original resource area. Kind of like double buffering for signal contexts. ------------- PR: https://git.openjdk.java.net/jdk/pull/6606 From shade at openjdk.java.net Tue Nov 30 10:47:55 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 30 Nov 2021 10:47:55 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: 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` Aleksey Shipilev 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 seven additional commits since the last revision: - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - Fix a comment - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - More reviews - Review feedback - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace - Initial work: runs async-profiler successfully ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5848/files - new: https://git.openjdk.java.net/jdk/pull/5848/files/bc4ba33b..373f15ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5848&range=03-04 Stats: 22783 lines in 424 files changed: 13220 ins; 6227 del; 3336 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 aph at openjdk.java.net Tue Nov 30 11:29:11 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 30 Nov 2021 11:29:11 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 10:47:55 GMT, Aleksey Shipilev wrote: >> 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` > > Aleksey Shipilev 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 seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - Fix a comment > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - More reviews > - Review feedback > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - Initial work: runs async-profiler successfully src/hotspot/cpu/zero/frame_zero.cpp line 139: > 137: assert(is_interpreted_frame(), "Not an interpreted frame"); > 138: // These are reasonable sanity checks > 139: if (fp() == 0 || (intptr_t(fp()) & (wordSize-1)) != 0) { Use `is_aligned()` here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From shade at openjdk.java.net Tue Nov 30 13:01:13 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 30 Nov 2021 13:01:13 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:26:04 GMT, Andrew Haley wrote: >> Aleksey Shipilev 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Fix a comment >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - More reviews >> - Review feedback >> - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace >> - Initial work: runs async-profiler successfully > > src/hotspot/cpu/zero/frame_zero.cpp line 139: > >> 137: assert(is_interpreted_frame(), "Not an interpreted frame"); >> 138: // These are reasonable sanity checks >> 139: if (fp() == 0 || (intptr_t(fp()) & (wordSize-1)) != 0) { > > Use `is_aligned()` here? I could, but this matches what other platforms are doing in their `frame::is_interpreted_frame_valid()`. If there are no other fixes needed, okay if I keep this one in place? Otherwise, I would need to re-test the whole thing for a minor touchup, which is tedious. ------------- PR: https://git.openjdk.java.net/jdk/pull/5848 From sspitsyn at openjdk.java.net Tue Nov 30 23:23:24 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 30 Nov 2021 23:23:24 GMT Subject: RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote: > This change seems to keep the test case in the bug from crashing in the ResourceMark destructor. We have a ResourceMark during stack walking in AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk. > Testing tier1-6 in progress. Hi Coleen, I'm okay with this work around. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6606 From sspitsyn at openjdk.java.net Tue Nov 30 23:26:32 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 30 Nov 2021 23:26:32 GMT Subject: RFR: 8274903: Zero: Support AsyncGetCallTrace [v5] In-Reply-To: References: Message-ID: <9Qsyq7smTvNNP3a7WwtYaMDiGesLCvPWF1FTxArevT0=.aa62eb0d-0fbd-4f5b-a15c-5553cf88ecff@github.com> On Tue, 30 Nov 2021 10:47:55 GMT, Aleksey Shipilev wrote: >> 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` > > Aleksey Shipilev 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 seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - Fix a comment > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - More reviews > - Review feedback > - Merge branch 'master' into JDK-8274903-zero-asyncgetcalltrace > - Initial work: runs async-profiler successfully Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5848