From duke at openjdk.org Mon Jul 1 03:49:25 2024 From: duke at openjdk.org (duke) Date: Mon, 1 Jul 2024 03:49:25 GMT Subject: RFR: 8331466: Problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all In-Reply-To: References: Message-ID: On Wed, 1 May 2024 14:14:22 GMT, SendaoYan wrote: > Hi, > GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64. > > Only change the ProblemList, no risk. @sendaoYan Your change (at version 16aa527b3552fad2ae6effe526b888b823973493) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2094774706 From duke at openjdk.org Mon Jul 1 03:49:26 2024 From: duke at openjdk.org (duke) Date: Mon, 1 Jul 2024 03:49:26 GMT Subject: RFR: 8331466: Problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all [v2] In-Reply-To: References: Message-ID: On Wed, 8 May 2024 01:19:05 GMT, SendaoYan wrote: >> Hi, >> GHA [runner](https://github.com/sendaoYan/jdk-ysd/actions/runs/8881868940/job/24386063136) shows that serviceability/dcmd/gc/RunFinalizationTest.java intermittent fail on macos-aarch64. The testcase has been problemlisted on linux-all,windows-x64,aix-ppc64. I think we should add the problemlist with macos-aarch64. >> >> Only change the ProblemList, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > problemlist serviceability/dcmd/gc/RunFinalizationTest.java on generic-all @sendaoYan Your change (at version fc1ef659520df5198adbda0dc4425db39c7cb138) is now ready to be sponsored by a Committer. @sendaoYan Your change (at version fc1ef659520df5198adbda0dc4425db39c7cb138) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2100434915 PR Comment: https://git.openjdk.org/jdk/pull/19033#issuecomment-2103669573 From jwaters at openjdk.org Mon Jul 1 04:17:17 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 1 Jul 2024 04:17:17 GMT Subject: RFR: 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp In-Reply-To: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> References: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> Message-ID: <03kxq5h91-B_yT-WWrkBGew9-Ncp2ZUvMbfMR64ICV4=.53d2da6f-772e-457c-b813-ea1bfbfff6b0@github.com> On Sun, 30 Jun 2024 22:15:34 GMT, Kim Barrett wrote: > Please review this trivial change to the print_method function in > test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE* > argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning > is enabled. The change is to replace that 0 with nullptr. > > This removes about 10% of the -Wzero-as-null-pointer-constant warnings when > building with that option. > > Testing: mach5 tier1 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19962#pullrequestreview-2150361649 From duke at openjdk.org Mon Jul 1 07:19:48 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 1 Jul 2024 07:19:48 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: > 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: Adapt code style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19055/files - new: https://git.openjdk.org/jdk/pull/19055/files/c625411b..8b200fc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=03-04 Stats: 27 lines in 1 file changed: 4 ins; 11 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/19055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055 PR: https://git.openjdk.org/jdk/pull/19055 From duke at openjdk.org Mon Jul 1 07:19:48 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 1 Jul 2024 07:19:48 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v4] In-Reply-To: References: Message-ID: <0t1u7cj5GqWW5rYe034pXVAhfZ09Lq9zOK80whDD3yE=.21eb2f23-d566-452f-88e0-e88926df35cc@github.com> On Fri, 28 Jun 2024 18:02:28 GMT, Kevin Walls wrote: >> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test for the elevated privileges case > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java: > > It's going to be mostly style nits. 8-) > I realise some of this was passed back and forth above (so apologies to you and to Larry for being a pain). > > > line 281 line break before IOException > > > 313 > There is no hard limit on line length, but when you add new longest lines it's probably diverged from the file's style. > Could you make some of the new comments more terse? > > > A lot of the new code is double-spaced, which is unusual for the file for HotSpot/JDK as a whole. > Is it still readable to you if we delete at least these empty lines: > 274, 276, 286, 296, 303, 312, 317, 319, 324, 326 > > It may not quite get findTargetProcessTmpDirectory to fit on screen, but it will help. 8-) Hi again @kevinjwalls, Thanks a lot for the review! And no worries :) I'm happy to adapt the code style to match the rest of the file and the JDK in general. I pushed some changes in 8b200fc7f1d4bb00a4f18c90cd8e36374ade98ba. I removed a lof of newlines and tried to make the comments more terse. The two `throw new IOException(String.format("unable to attach, %s non-existent! process: %d terminated", procPidPath, pid));` lines still stand out in terms of line length, should I wrap them? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2199413193 From cjplummer at openjdk.org Mon Jul 1 08:07:47 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 08:07:47 GMT Subject: RFR: 8313235: TestClhsdbJstackLock.java failed with '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class for LingeredAppWithLock\)$' missing from stdout/stderr Message-ID: Once the main thread has detected that the spawned thread is in the BLOCKED state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible on the top of the stack, but it is not, so the "waiting to lock" message is missing from the stack trace. I think the explanations mentioned in [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) and [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) apply here also. The state of the thread has moved to BLOCKED, but the thread still needs to finish making an OS call to actually become blocked and the thread become idle. During that time we may not be able to get an accurate stack trace. In this case probably SP has not been flushed, so we are not seeing the lockMethod() frame, which should appear at the top of the stack. A short delay has been added after all threads have entered the desired state to make sure they have fully reached the desired state and are now idle. Tested with Tier1 CI and all svc test tasks for tier2 and tier5. ------------- Commit messages: - Add a 1/2 second delay to make sure the threads have finished moving to the right state and and idle. Changes: https://git.openjdk.org/jdk/pull/19953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313235 Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19953/head:pull/19953 PR: https://git.openjdk.org/jdk/pull/19953 From cjplummer at openjdk.org Mon Jul 1 08:16:07 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 08:16:07 GMT Subject: RFR: 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 [v2] In-Reply-To: References: Message-ID: > On macosx-aarch64, sometimes the generated core file does not contain all valid memory. This causes SA tests to fail with various address related java exceptions. There's nothing SA can do to work around the problem, and these failures over time have been just too noisy, so I'm problem listing all the SA core files tests on macosx-aarch64. Note they are already problem listed on macosx-x64 dues to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) (the tests time out while generating the core dump because it takes way too long), so unfortunately this means no more core file testing on macosx, at least for now. > > Tested with tier1 and running all tier2 and tier5 SA test tasks. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Use proper CR in problem list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19950/files - new: https://git.openjdk.org/jdk/pull/19950/files/33c20cdc..958429ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19950&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19950&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/19950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19950/head:pull/19950 PR: https://git.openjdk.org/jdk/pull/19950 From sgehwolf at openjdk.org Mon Jul 1 08:50:31 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Jul 2024 08:50:31 GMT Subject: Integrated: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container In-Reply-To: References: Message-ID: <0hEDyLmsRgW-GR23fKnixv3_5edApaB_eoEQ2D_28NU=.32f148cd-e8a2-4bef-b8bc-44ec7cc0dbd0@github.com> On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote: > Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line: > > > [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present > > > This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example: > > > java -XshowSettings:system --version > Operating System Metrics: > Provider: cgroupv1 > System not containerized. > openjdk 23-internal 2024-09-17 > OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk) > OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing) > > > The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed. > > Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system. > > Testing: > > - [x] GHA (risc-v failure seems infra related) > - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests) > - [x] Some manual testing using cri-o > > Thoughts? This pull request has now been integrated. Changeset: 0a6ffa57 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/0a6ffa57954ddf4f92205205a5a1bada813d127a Stats: 411 lines in 20 files changed: 305 ins; 79 del; 27 mod 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container Reviewed-by: stuefe, iklam ------------- PR: https://git.openjdk.org/jdk/pull/18201 From sgehwolf at openjdk.org Mon Jul 1 08:50:29 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Jul 2024 08:50:29 GMT Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v8] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf wrote: >> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line: >> >> >> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present >> >> >> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example: >> >> >> java -XshowSettings:system --version >> Operating System Metrics: >> Provider: cgroupv1 >> System not containerized. >> openjdk 23-internal 2024-09-17 >> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk) >> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing) >> >> >> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed. >> >> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system. >> >> Testing: >> >> - [x] GHA (risc-v failure seems infra related) >> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests) >> - [x] Some manual testing using cri-o >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Refactor mount info matching to helper function > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Remove problem listing of PlainRead which is reworked here > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Add doc for mountinfo scanning. > - Unify naming of variables > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - Merge branch 'master' into jdk-8261242-is-containerized-fix > - ... and 8 more: https://git.openjdk.org/jdk/compare/486aa11e...1017da35 Thank you for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2199581201 From dfenacci at openjdk.org Mon Jul 1 09:11:30 2024 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 1 Jul 2024 09:11:30 GMT Subject: RFR: 8333891: Method excluded with directive is not compiled after removal of directive [v2] In-Reply-To: References: <2xstE3V0PD8FGcijx_THSX1YgIJ7fZLponoL7b96TiY=.04ecae5f-9e3a-4c26-9893-72822f31c753@github.com> Message-ID: On Sat, 22 Jun 2024 09:30:25 GMT, Evgeny Astigeevich wrote: >> A Java method can become non-compilable if there are issues with its compilation or if its compiled version causes problems. Additionally, a method can be marked as non-compilable using a compile command or a compiler directive. Since compiler directives can be updated, a directive that disables a method's compilation can be changed or removed. >> >> Currently, when a Java method is marked as non-compilable, the reason for this status is unknown. If a change in a compiler directive makes the method compilable again, we cannot clear the non-compilable status because we don't know if the directive initially caused the method to become non-compilable. >> >> To resolve the issue two method flags are introduced: `is_c1_exclude` and `is_c2_excluded`. They mean a Java method is excluded from compilation by a directive. With these flags we can find out a Java method has been excluded with a directive. If the directive changes and allows compilation of the method we can detect this and clear the non-compilable status. >> >> As accesses to flags must be race free we have to remove getting a directive from `CompileBroker::compile_method`. We combine two `CompileBroker::compile_method` into one. We also move calculation whether compilation is blocking into `CompileBroker::compile_method_base`. The directive used for that calculation is passed to a compile task, so a compile task does not need to get it again. >> >> A regression test is added. >> >> Tested fastdebug build on Linux AArch64, Linux x86_64 and Windows Server 2019 x86_64: >> - Tier1/2/3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix data race Changes requested by dfenacci (Committer). src/hotspot/share/compiler/compileBroker.cpp line 1336: > 1334: } > 1335: > 1336: AbstractCompiler *comp = CompileBroker::compiler(comp_level); Do we need to change this? src/hotspot/share/compiler/compileBroker.cpp line 1563: > 1561: // See if this compilation is not allowed. > 1562: bool CompileBroker::compilation_is_prohibited(const methodHandle& method, int osr_bci, int comp_level) { > 1563: assert(compiler(comp_level) != nullptr, "Ensure we have a compiler"); Are you sure `compiler(comp_level)` can never be `nullptr` (not even potentially)? (it seems so to me too but just to make sure) ------------- PR Review: https://git.openjdk.org/jdk/pull/19637#pullrequestreview-2148291624 PR Review Comment: https://git.openjdk.org/jdk/pull/19637#discussion_r1658904857 PR Review Comment: https://git.openjdk.org/jdk/pull/19637#discussion_r1660722626 From kevinw at openjdk.org Mon Jul 1 09:33:31 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 1 Jul 2024 09:33:31 GMT Subject: RFR: 8269881: SA stack dump fails to include stack trace for SteadyStateThread In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer wrote: > The completely unrelated fix to [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe that the issue with sometimes not being able to get the stack trace of the SteadyStateThread might be due to the thread being active for a short period after being reported as in the Thread.State.BLOCKED state. Once set to that state, the thread still needs to call a native OS API to block the thread so it is truly idle. During this time the thread stack might be inconsistent and not walk-able. The fix is to add a short sleep after the thread has moved to the Thread.State.BLOCKED state to give it a chance to finish blocking. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. Looks good, let's try it! Was wondering if for the failure in ClhsdbDumpheap.java, the missing text was too far from when LingeredApp was started. But if it's the first subtest, then it's the stacks in a dumpheap output where we don't find the required steadyState text. So the test only has to create the array of subtests and call the first one, before the LingeredApp thread has really blocked... Good to make this harmless test change so we get long term testing of it. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2150892788 From kevinw at openjdk.org Mon Jul 1 10:00:17 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 1 Jul 2024 10:00:17 GMT Subject: RFR: 8313235: TestClhsdbJstackLock.java failed with '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class for LingeredAppWithLock\)$' missing from stdout/stderr In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 22:30:52 GMT, Chris Plummer wrote: > Once the main thread has detected that the spawned thread is in the BLOCKED state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible on the top of the stack, but it is not, so the "waiting to lock" message is missing from the stack trace. > > I think the explanations mentioned in [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) and [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) apply here also. The state of the thread has moved to BLOCKED, but the thread still needs to finish making an OS call to actually become blocked and the thread become idle. During that time we may not be able to get an accurate stack trace. In this case probably SP has not been flushed, so we are not seeing the lockMethod() frame, which should appear at the top of the stack. > > A short delay has been added after all threads have entered the desired state to make sure they have fully reached the desired state and are now idle. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. Looks good. I think its more productive to make these harmless test updates than to count nanoseconds and try to reason about some of these failures. Reading LingeredApp I notice waitAppReadyOrCrashed() is really "wait until alive, or crashed", it has no idea if LingeredApp is "ready". TestClhsdbJstackLock does not waiting, just relies on LingeredApp.startApp(), so this delay should help. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19953#pullrequestreview-2150951040 From kevinw at openjdk.org Mon Jul 1 10:04:30 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 1 Jul 2024 10:04:30 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: <6rjcuUBTaePQ77eX8Jlc2Q0lfZYRkj0xGNKH8lKPGoU=.8b2e6c3e-2259-4815-b642-7c9656b73c0f@github.com> On Mon, 1 Jul 2024 07:19:48 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: > > Adapt code style That all looks reasonable to me, thanks. We have a two reviewer requirement in hotspot generally so let's try and get further comment/review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2199734377 From aboldtch at openjdk.org Mon Jul 1 10:27:23 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Jul 2024 10:27:23 GMT Subject: [jdk23] RFR: 8326820: Metadata artificially kept alive In-Reply-To: <9401T6FMpCnxvfgCCxHR-7-wEcwchAqf_ETKFbQSXg0=.096ce771-f64a-4e41-bb3a-94a1b232965c@github.com> References: <9401T6FMpCnxvfgCCxHR-7-wEcwchAqf_ETKFbQSXg0=.096ce771-f64a-4e41-bb3a-94a1b232965c@github.com> Message-ID: On Thu, 27 Jun 2024 14:30:43 GMT, Axel Boldt-Christmas wrote: > Hi all, > > This pull request contains a backport of commit [5909d541](https://github.com/openjdk/jdk/commit/5909d54147355dd7da5786ff39ead4c15816705c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 27 Jun 2024 and was reviewed by Erik ?sterlund, Stefan Karlsson and Coleen Phillimore. > > Thanks! Thanks for the review. This has been running through the JDK 24 CI over the weekend. No issues found. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19929#issuecomment-2199778367 From aboldtch at openjdk.org Mon Jul 1 10:27:24 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Jul 2024 10:27:24 GMT Subject: [jdk23] Integrated: 8326820: Metadata artificially kept alive In-Reply-To: <9401T6FMpCnxvfgCCxHR-7-wEcwchAqf_ETKFbQSXg0=.096ce771-f64a-4e41-bb3a-94a1b232965c@github.com> References: <9401T6FMpCnxvfgCCxHR-7-wEcwchAqf_ETKFbQSXg0=.096ce771-f64a-4e41-bb3a-94a1b232965c@github.com> Message-ID: On Thu, 27 Jun 2024 14:30:43 GMT, Axel Boldt-Christmas wrote: > Hi all, > > This pull request contains a backport of commit [5909d541](https://github.com/openjdk/jdk/commit/5909d54147355dd7da5786ff39ead4c15816705c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 27 Jun 2024 and was reviewed by Erik ?sterlund, Stefan Karlsson and Coleen Phillimore. > > Thanks! This pull request has now been integrated. Changeset: e5fbc631 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/e5fbc631ca06b40a682149b0903221e190f592aa Stats: 80 lines in 6 files changed: 31 ins; 25 del; 24 mod 8326820: Metadata artificially kept alive Reviewed-by: stefank Backport-of: 5909d54147355dd7da5786ff39ead4c15816705c ------------- PR: https://git.openjdk.org/jdk/pull/19929 From coleenp at openjdk.org Mon Jul 1 12:19:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Jul 2024 12:19:21 GMT Subject: [jdk23] RFR: 8333542: Breakpoint in parallel code does not work In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 12:14:55 GMT, Coleen Phillimore wrote: > Clean backport of JDK-8333542. After this, we need a backport for JDK-8335134 to fix the test. Thank you Chris. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19938#issuecomment-2199990801 From coleenp at openjdk.org Mon Jul 1 12:19:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Jul 2024 12:19:22 GMT Subject: [jdk23] Integrated: 8333542: Breakpoint in parallel code does not work In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 12:14:55 GMT, Coleen Phillimore wrote: > Clean backport of JDK-8333542. After this, we need a backport for JDK-8335134 to fix the test. This pull request has now been integrated. Changeset: 7040de19 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/7040de19bdb29a3abacf2a39b7c7c30a07c61135 Stats: 516 lines in 16 files changed: 339 ins; 129 del; 48 mod 8333542: Breakpoint in parallel code does not work Reviewed-by: cjplummer Backport-of: b3bf31a0a08da679ec2fd21613243fb17b1135a9 ------------- PR: https://git.openjdk.org/jdk/pull/19938 From kevinw at openjdk.org Mon Jul 1 12:59:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 1 Jul 2024 12:59:21 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 07:19:48 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: > > Adapt code style Looks good to me, thanks! (!havePidNSes && nsPid > 1) I didn't get this at first, I think it's because PID 1 can't have a parent? (in the same namespace) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19055#pullrequestreview-2151324535 PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2200071296 From larry.cable at oracle.com Mon Jul 1 14:56:01 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Mon, 1 Jul 2024 07:56:01 -0700 Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: <8480a5aa-2e0d-45d5-b8d7-7c7cf0db9dc9@oracle.com> On 7/1/24 5:59 AM, Kevin Walls wrote: > On Mon, 1 Jul 2024 07:19:48 GMT, Sebastian L?vdahl wrote: > >>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) >> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: >> >> Adapt code style > Looks good to me, thanks! > > (!havePidNSes && nsPid > 1) > I didn't get this at first, I think it's because PID 1 can't have a parent? (in the same namespace) that's correct > > ------------- > > Marked as reviewed by kevinw (Reviewer). > > PR Review: https://git.openjdk.org/jdk/pull/19055#pullrequestreview-2151324535 > PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2200071296 From eastigeevich at openjdk.org Mon Jul 1 16:58:19 2024 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Jul 2024 16:58:19 GMT Subject: RFR: 8333891: Method excluded with directive is not compiled after removal of directive [v2] In-Reply-To: References: <2xstE3V0PD8FGcijx_THSX1YgIJ7fZLponoL7b96TiY=.04ecae5f-9e3a-4c26-9893-72822f31c753@github.com> Message-ID: <-HY4OUWbYiZZbcAY5ZqewIdDR-QAweVwJP1KsfPZuv8=.440ce429-aaef-4e6a-b13e-4f0645e87581@github.com> On Sat, 22 Jun 2024 09:30:25 GMT, Evgeny Astigeevich wrote: >> A Java method can become non-compilable if there are issues with its compilation or if its compiled version causes problems. Additionally, a method can be marked as non-compilable using a compile command or a compiler directive. Since compiler directives can be updated, a directive that disables a method's compilation can be changed or removed. >> >> Currently, when a Java method is marked as non-compilable, the reason for this status is unknown. If a change in a compiler directive makes the method compilable again, we cannot clear the non-compilable status because we don't know if the directive initially caused the method to become non-compilable. >> >> To resolve the issue two method flags are introduced: `is_c1_exclude` and `is_c2_excluded`. They mean a Java method is excluded from compilation by a directive. With these flags we can find out a Java method has been excluded with a directive. If the directive changes and allows compilation of the method we can detect this and clear the non-compilable status. >> >> As accesses to flags must be race free we have to remove getting a directive from `CompileBroker::compile_method`. We combine two `CompileBroker::compile_method` into one. We also move calculation whether compilation is blocking into `CompileBroker::compile_method_base`. The directive used for that calculation is passed to a compile task, so a compile task does not need to get it again. >> >> A regression test is added. >> >> Tested fastdebug build on Linux AArch64, Linux x86_64 and Windows Server 2019 x86_64: >> - Tier1/2/3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix data race Hi @dafedafe, Thank you for reviewing. ------------- PR Review: https://git.openjdk.org/jdk/pull/19637#pullrequestreview-2151784002 From eastigeevich at openjdk.org Mon Jul 1 16:58:20 2024 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 1 Jul 2024 16:58:20 GMT Subject: RFR: 8333891: Method excluded with directive is not compiled after removal of directive [v2] In-Reply-To: References: <2xstE3V0PD8FGcijx_THSX1YgIJ7fZLponoL7b96TiY=.04ecae5f-9e3a-4c26-9893-72822f31c753@github.com> Message-ID: On Fri, 28 Jun 2024 15:15:31 GMT, Damon Fenacci wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix data race > > src/hotspot/share/compiler/compileBroker.cpp line 1336: > >> 1334: } >> 1335: >> 1336: AbstractCompiler *comp = CompileBroker::compiler(comp_level); > > Do we need to change this? Not really. I'll change it back to the original code. > src/hotspot/share/compiler/compileBroker.cpp line 1563: > >> 1561: // See if this compilation is not allowed. >> 1562: bool CompileBroker::compilation_is_prohibited(const methodHandle& method, int osr_bci, int comp_level) { >> 1563: assert(compiler(comp_level) != nullptr, "Ensure we have a compiler"); > > Are you sure `compiler(comp_level)` can never be `nullptr` (not even potentially)? (it seems so to me too but just to make sure) Yes, I am sure. This is a private member function which is only used in `CompileBroker::compile_method`. In `CompileBroker::compile_method` there has always been an assert checking availability of a compiler. I added the assert here just in case the function is used in any other functions where a compiler might not be available. If we want to minimize changes, we can keep the original code where the parameter `excluded` is only deleted. The checks `comp == nullptr` are redundant in the original code because the function is invoked as follows: if (comp == nullptr || compilation_is_prohibited(...)) { return nullptr; } I can add a check `comp == nullptr` at the beginning of the function and return `nullptr` if it is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19637#discussion_r1661286156 PR Review Comment: https://git.openjdk.org/jdk/pull/19637#discussion_r1661319021 From cjplummer at openjdk.org Mon Jul 1 17:15:32 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 17:15:32 GMT Subject: [jdk23] RFR: 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout Message-ID: Clean backport. Need to backport this since it was introduced with the new test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has also been backpoted to 23. ------------- Commit messages: - Backport 4e8cbf884ab1eee9c3110712ab62edc706e948ba Changes: https://git.openjdk.org/jdk/pull/19976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19976&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335134 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19976/head:pull/19976 PR: https://git.openjdk.org/jdk/pull/19976 From duke at openjdk.org Mon Jul 1 17:23:20 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 1 Jul 2024 17:23:20 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 12:55:24 GMT, Kevin Walls wrote: >(!havePidNSes && nsPid > 1) > I didn't get this at first, I think it's because PID 1 can't have a parent? (in the same namespace) That was my assumption as well. Is that correct @larry-cable? Maybe it could be worth clarifying with a comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2200666442 From mgronlun at openjdk.org Mon Jul 1 17:51:25 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 1 Jul 2024 17:51:25 GMT Subject: RFR: 8322812: Manpage for jcmd is missing JFR.view command In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 14:51:57 GMT, Erik Gahlin wrote: > Could I have a review of a change to the jcmd man page? A typo was also fixed for JFR.start. > > Testing: tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19942#pullrequestreview-2148543225 From kevinw at openjdk.org Mon Jul 1 17:51:26 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 1 Jul 2024 17:51:26 GMT Subject: RFR: 8322812: Manpage for jcmd is missing JFR.view command In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 14:51:57 GMT, Erik Gahlin wrote: > Could I have a review of a change to the jcmd man page? A typo was also fixed for JFR.start. > > Testing: tier1 > > Thanks > Erik Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19942#pullrequestreview-2151862195 From egahlin at openjdk.org Mon Jul 1 17:51:25 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 1 Jul 2024 17:51:25 GMT Subject: RFR: 8322812: Manpage for jcmd is missing JFR.view command Message-ID: Could I have a review of a change to the jcmd man page? A typo was also fixed for JFR.start. Testing: tier1 Thanks Erik ------------- Commit messages: - Don't touch version - Review feedback - Initial Changes: https://git.openjdk.org/jdk/pull/19942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322812 Stats: 50 lines in 1 file changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19942/head:pull/19942 PR: https://git.openjdk.org/jdk/pull/19942 From cjplummer at openjdk.org Mon Jul 1 18:31:19 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 18:31:19 GMT Subject: RFR: 8269881: SA stack dump fails to include stack trace for SteadyStateThread In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:31:12 GMT, Kevin Walls wrote: >> The completely unrelated fix to [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe that the issue with sometimes not being able to get the stack trace of the SteadyStateThread might be due to the thread being active for a short period after being reported as in the Thread.State.BLOCKED state. Once set to that state, the thread still needs to call a native OS API to block the thread so it is truly idle. During this time the thread stack might be inconsistent and not walk-able. The fix is to add a short sleep after the thread has moved to the Thread.State.BLOCKED state to give it a chance to finish blocking. >> >> Tested with Tier1 CI and all svc test tasks for tier2 and tier5. > > Looks good, let's try it! > > Was wondering if for the failure in ClhsdbDumpheap.java, the missing text was too far from when LingeredApp was started. But if it's the first subtest, then it's the stacks in a dumpheap output where we don't find the required steadyState text. So the test only has to create the array of subtests and call the first one, before the LingeredApp thread has really blocked... > > Good to make this harmless test change so we get long term testing of it. @kevinjwalls Actually in all cases after launching LingeredApp and waiting for the the SteadyStateThread to be "ready", there is still then the launching of the clhsdb tool, which is going to take some time. Seems hard to believe that the SteadyStateThread would ever lose out on that race. I get the feeling that maybe there is more going on here than I initially thought. Almost all of these failures are on Windows (about 22 out of 25) with the other 3 on linux-arm. Maybe sometimes there is some sort of OS hiccup that is delaying the SteadyStateThread. In any case, no real harm with this fix, and hopefully it helps ------------- PR Comment: https://git.openjdk.org/jdk/pull/19951#issuecomment-2200769458 From dholmes at openjdk.org Mon Jul 1 22:11:18 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Jul 2024 22:11:18 GMT Subject: [jdk23] RFR: 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 17:10:44 GMT, Chris Plummer wrote: > Clean backport. Need to backport this since it was introduced with the new test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has also been backpoted to 23. Backport looks accurate. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19976#pullrequestreview-2152315588 From cjplummer at openjdk.org Mon Jul 1 22:46:21 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 22:46:21 GMT Subject: [jdk23] RFR: 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 17:10:44 GMT, Chris Plummer wrote: > Clean backport. Need to backport this since it was introduced with the new test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has also been backpoted to 23. Thanks David! Integrating now since without this backport we might start seeing some new CI failures due to [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542) having been backported earlier today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19976#issuecomment-2201260668 From cjplummer at openjdk.org Mon Jul 1 22:46:22 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Jul 2024 22:46:22 GMT Subject: [jdk23] Integrated: 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 17:10:44 GMT, Chris Plummer wrote: > Clean backport. Need to backport this since it was introduced with the new test in [JDK-8333542](https://bugs.openjdk.org/browse/JDK-8333542), which has also been backpoted to 23. This pull request has now been integrated. Changeset: 9d744b0e Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/9d744b0e04cdf4be8d9e3d5435f8bc108bda0206 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout Reviewed-by: dholmes Backport-of: 4e8cbf884ab1eee9c3110712ab62edc706e948ba ------------- PR: https://git.openjdk.org/jdk/pull/19976 From stuefe at openjdk.org Tue Jul 2 06:30:22 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 2 Jul 2024 06:30:22 GMT Subject: RFR: 8332124: Jcmd processing should accept the "help" sub option as command argument [v3] In-Reply-To: <8p8hP60z5o6v5WA6Do1F402rsOhbfzQOA6bIjCmcRBI=.203cd616-a4e1-4cb1-b6b8-5e306c88cf7d@github.com> References: <8p8hP60z5o6v5WA6Do1F402rsOhbfzQOA6bIjCmcRBI=.203cd616-a4e1-4cb1-b6b8-5e306c88cf7d@github.com> Message-ID: On Fri, 28 Jun 2024 14:39:12 GMT, Sonia Zaldana Calles wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision: >> >> - Updating copyright header >> - Modifying usage to --help and -help. Updated ensuing test case to test both >> - Updating copyright headers > > One question. With the current implementation, this is the check in place to offer help: > ```strncmp(args, " -help", 6) == 0 || strncmp(args, " --help", 7)``` > > I could change this to do `strncmp(args, " -h", 3)` instead but this is a bit problematic as it would block any future flags that start out with `-h` from working. > > I've been giving this some thought on how to implement a restrictive way to check only for the arguments `-h` or `-help` while also allowing for other arguments to be passed afterwards that should be ignored. > > I thought about perhaps using some type of regex matching with ```std:regex``` but hotspot doesn't allow the use of global operators new and delete. I don't want to overengineer this piece of logic so I was wondering if there was a regex matching utility that I could leverage in HotSpot? > > The alternative would be to make the check more restrictive and not allow for arguments after `-h` has been issued i.e. `strcmp(args, "-h") == 0`. > > Thanks for your help! Hi @SoniaZaldana sorry for the delay, I'm snowed in atm. > One question. With the current implementation, this is the check in place to offer help: `strncmp(args, " -help", 6) == 0 || strncmp(args, " --help", 7)` > > I could change this to do `strncmp(args, " -h", 3)` instead but this is a bit problematic as it would block any future flags that start out with `-h` from working. Well, we restrict future compatibility no matter what we do. > > I've been giving this some thought on how to implement a restrictive way to check only for the arguments `-h` or `-help` while also allowing for other arguments to be passed afterwards that should be ignored. > > I thought about perhaps using some type of regex matching with `std:regex` but hotspot doesn't allow the use of global operators new and delete. God no :) > I don't want to overengineer this piece of logic so I was wondering if there was a regex matching utility that I could leverage in HotSpot? No need, you can do this with normal C tools. with p pointing to start of arguments: - forward p and walk all spaces, break out for \0 - strncmp with "-h", size 2 - if follow-up char is either blank or \0, its a help command. If we agree to just ignore follow up arguments, you can now just rebuild the command as "help commandname". - bonus for writing a warning if there are arguments after help > > The alternative would be to make the check more restrictive and not allow for arguments after `-h` has been issued i.e. `strcmp(args, "-h") == 0`. > > Thanks for your help! Cheers ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2202046212 From tschatzl at openjdk.org Tue Jul 2 07:47:58 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 2 Jul 2024 07:47:58 GMT Subject: RFR: 8331385: G1: Prefix HeapRegion helper classes with G1 Message-ID: Hi all, after [JDK-8330694](https://bugs.openjdk.org/browse/JDK-8330694) which renamed HeapRegion to G1HeapRegion, there were a few related helper classes in this CR that were not renamed. It's purely mechanical renaming without even further renaming of files etc. This change updates them. (Fwiw, the "Viewed" checkbox at the top right of the file change helps a lot review this change incrementally) Testing: tier1, tier4, tier5 Thanks, Thomas ------------- Commit messages: - 8331385 Changes: https://git.openjdk.org/jdk/pull/19967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331385 Stats: 887 lines in 68 files changed: 163 ins; 165 del; 559 mod Patch: https://git.openjdk.org/jdk/pull/19967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19967/head:pull/19967 PR: https://git.openjdk.org/jdk/pull/19967 From ayang at openjdk.org Tue Jul 2 10:24:18 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Jul 2024 10:24:18 GMT Subject: RFR: 8331385: G1: Prefix HeapRegion helper classes with G1 In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:35:00 GMT, Thomas Schatzl wrote: > Hi all, > > after [JDK-8330694](https://bugs.openjdk.org/browse/JDK-8330694) which renamed HeapRegion to G1HeapRegion, there were a few related helper classes in this CR that were not renamed. > > It's purely mechanical renaming without even further renaming of files etc. > > This change updates them. > > (Fwiw, the "Viewed" checkbox at the top right of the file change helps a lot review this change incrementally) > > Testing: tier1, tier4, tier5 > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19967#pullrequestreview-2153390622 From duke at openjdk.org Tue Jul 2 11:07:56 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Tue, 2 Jul 2024 11:07:56 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v6] In-Reply-To: References: Message-ID: > 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: Clarify PID 1 check with comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19055/files - new: https://git.openjdk.org/jdk/pull/19055/files/8b200fc7..543036bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19055&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055 PR: https://git.openjdk.org/jdk/pull/19055 From duke at openjdk.org Tue Jul 2 11:07:56 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Tue, 2 Jul 2024 11:07:56 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v5] In-Reply-To: References: Message-ID: <66nISy5dfucGp_1hULFxcqm2sV-CIo53f8xP9PyZuLY=.f85aada1-620b-4a54-9f1b-778bda5cae95@github.com> On Mon, 1 Jul 2024 07:19:48 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: > > Adapt code style Thanks for the confirmation Larry. I added a small comment about it. diff --git src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java index 91ffea2ab87..0e76152c1e3 100644 --- src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java +++ src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java @@ -297,7 +297,7 @@ private String findTargetProcessTmpDirectory(long pid, long ns_pid) throws Attac } } - // let's attempt to obtain the pid NS, best efforts to avoid crossing pid ns boundaries (as with a container) + // let's attempt to obtain the pid ns, best efforts to avoid crossing pid ns boundaries (as with a container) Optional curPidNS = Optional.empty(); try { @@ -311,7 +311,7 @@ private String findTargetProcessTmpDirectory(long pid, long ns_pid) throws Attac // the process still exists, but we don't have privileges to read its procfs } - // recurse "up" the process hierarchy, if appropriate + // recurse "up" the process hierarchy if appropriate. PID 1 cannot have a parent in the same namespace final var havePidNSes = prevPidNS.isPresent() && curPidNS.isPresent(); final var ppid = ph.get().parent(); ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2202761731 From marcus.hirt at datadoghq.com Tue Jul 2 12:41:21 2024 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Tue, 2 Jul 2024 14:41:21 +0200 Subject: Virtual Serviceability Meetup 2024 Message-ID: Hi all, We're organizing another OpenJDK Serviceability Meetup! Last time [1] 41 attendees from various companies (Oracle, Red Hat, Amazon, SAP, Datadog, VMware and more) came together to discuss problems and potential solutions related to OpenJDK serviceability. Following the last meetup, I ran a poll, which once again showed that the attendees had great fun, and that there is a wish to hold the Serviceability Meetup every 6 months on average. This time, it will be a little less than a year since the last one. (I think it's likely that we settle on making this an annual autumn event.) Here's a link to the invite form, should you be interested in participating: https://forms.gle/JUiBZm7D7DkMZhV28 Hope to see you there! Kind regards, Marcus [1]: https://mail.openjdk.org/pipermail/serviceability-dev/2023-October/051723.html From szaldana at openjdk.org Tue Jul 2 15:13:49 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 2 Jul 2024 15:13:49 GMT Subject: RFR: 8332124: Jcmd processing should accept the "help" sub option as command argument [v4] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to accept "help" as an argument to subcommands. > > Testing: > - [x] Verified running `jcmd 4711 VM.metaspace help` works along with other subcommands. > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Enabling only -h or --help. Also modifying test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19776/files - new: https://git.openjdk.org/jdk/pull/19776/files/74a563ae..65cab4d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=02-03 Stats: 27 lines in 3 files changed: 13 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/19776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19776/head:pull/19776 PR: https://git.openjdk.org/jdk/pull/19776 From szaldana at openjdk.org Tue Jul 2 15:21:49 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 2 Jul 2024 15:21:49 GMT Subject: RFR: 8332124: Jcmd processing should accept the "help" sub option as command argument [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to accept "help" as an argument to subcommands. > > Testing: > - [x] Verified running `jcmd 4711 VM.metaspace help` works along with other subcommands. > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Making enabling help more restrictive. Will not accept -help ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19776/files - new: https://git.openjdk.org/jdk/pull/19776/files/65cab4d3..4e2a4493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19776/head:pull/19776 PR: https://git.openjdk.org/jdk/pull/19776 From kevinw at openjdk.org Tue Jul 2 17:28:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 2 Jul 2024 17:28:25 GMT Subject: RFR: 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 [v2] In-Reply-To: References: Message-ID: <_Y11hvcYui60VbAETF8dC7msBVMrHUYfWcy9E1OeQ0I=.77fa2e23-61ad-40e0-b967-0b435c6d97f4@github.com> On Mon, 1 Jul 2024 08:16:07 GMT, Chris Plummer wrote: >> On macosx-aarch64, sometimes the generated core file does not contain all valid memory. This causes SA tests to fail with various address related java exceptions. There's nothing SA can do to work around the problem, and these failures over time have been just too noisy, so I'm problem listing all the SA core files tests on macosx-aarch64. Note they are already problem listed on macosx-x64 dues to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) (the tests time out while generating the core dump because it takes way too long), so unfortunately this means no more core file testing on macosx, at least for now. >> >> Tested with tier1 and running all tier2 and tier5 SA test tasks. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use proper CR in problem list Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19950#pullrequestreview-2154452078 From amenkov at openjdk.org Tue Jul 2 17:56:23 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 2 Jul 2024 17:56:23 GMT Subject: RFR: 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp In-Reply-To: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> References: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> Message-ID: On Sun, 30 Jun 2024 22:15:34 GMT, Kim Barrett wrote: > Please review this trivial change to the print_method function in > test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE* > argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning > is enabled. The change is to replace that 0 with nullptr. > > This removes about 10% of the -Wzero-as-null-pointer-constant warnings when > building with that option. > > Testing: mach5 tier1 Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19962#pullrequestreview-2154513850 From amenkov at openjdk.org Tue Jul 2 17:58:19 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 2 Jul 2024 17:58:19 GMT Subject: RFR: 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 08:16:07 GMT, Chris Plummer wrote: >> On macosx-aarch64, sometimes the generated core file does not contain all valid memory. This causes SA tests to fail with various address related java exceptions. There's nothing SA can do to work around the problem, and these failures over time have been just too noisy, so I'm problem listing all the SA core files tests on macosx-aarch64. Note they are already problem listed on macosx-x64 dues to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) (the tests time out while generating the core dump because it takes way too long), so unfortunately this means no more core file testing on macosx, at least for now. >> >> Tested with tier1 and running all tier2 and tier5 SA test tasks. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use proper CR in problem list Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19950#pullrequestreview-2154516441 From cjplummer at openjdk.org Tue Jul 2 18:16:26 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 2 Jul 2024 18:16:26 GMT Subject: RFR: 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 08:16:07 GMT, Chris Plummer wrote: >> On macosx-aarch64, sometimes the generated core file does not contain all valid memory. This causes SA tests to fail with various address related java exceptions. There's nothing SA can do to work around the problem, and these failures over time have been just too noisy, so I'm problem listing all the SA core files tests on macosx-aarch64. Note they are already problem listed on macosx-x64 dues to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) (the tests time out while generating the core dump because it takes way too long), so unfortunately this means no more core file testing on macosx, at least for now. >> >> Tested with tier1 and running all tier2 and tier5 SA test tasks. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use proper CR in problem list Thanks Alex and Kevin! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19950#issuecomment-2203998746 From cjplummer at openjdk.org Tue Jul 2 18:16:27 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 2 Jul 2024 18:16:27 GMT Subject: Integrated: 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 17:49:10 GMT, Chris Plummer wrote: > On macosx-aarch64, sometimes the generated core file does not contain all valid memory. This causes SA tests to fail with various address related java exceptions. There's nothing SA can do to work around the problem, and these failures over time have been just too noisy, so I'm problem listing all the SA core files tests on macosx-aarch64. Note they are already problem listed on macosx-x64 dues to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) (the tests time out while generating the core dump because it takes way too long), so unfortunately this means no more core file testing on macosx, at least for now. > > Tested with tier1 and running all tier2 and tier5 SA test tasks. This pull request has now been integrated. Changeset: a3479576 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/a3479576c9b3e557cdc04e0984da6350e985dcc9 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754 Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/19950 From sspitsyn at openjdk.org Tue Jul 2 20:27:19 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Jul 2024 20:27:19 GMT Subject: RFR: 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp In-Reply-To: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> References: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> Message-ID: On Sun, 30 Jun 2024 22:15:34 GMT, Kim Barrett wrote: > Please review this trivial change to the print_method function in > test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE* > argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning > is enabled. The change is to replace that 0 with nullptr. > > This removes about 10% of the -Wzero-as-null-pointer-constant warnings when > building with that option. > > Testing: mach5 tier1 Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19962#pullrequestreview-2154808436 From duke at openjdk.org Tue Jul 2 20:51:25 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jul 2024 20:51:25 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: <7MY3EAfeQYRlSLnyELgdm-yZ1_t1BrAtGASTdlzde-Q=.84327af4-9564-45f1-b47e-97fe7259b6f7@github.com> On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > Signed-off-by: sendaoYan @sendaoYan Your change (at version d1eb4fac03a1ebd4a519f132332cd527afe2090b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-1906039488 From dlong at openjdk.org Tue Jul 2 20:51:25 2024 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Jul 2024 20:51:25 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed > > Signed-off-by: sendaoYan Why does 8M trigger the OOM Killer, but 1M does not? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2204387282 From egahlin at openjdk.org Tue Jul 2 22:53:45 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 2 Jul 2024 22:53:45 GMT Subject: RFR: 8322812: Manpage for jcmd is missing JFR.view command [v2] In-Reply-To: References: Message-ID: > Could I have a review of a change to the jcmd man page? > > Testing: tier1 > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision: - Remove accidentally added file - Remove fix of typo. It will be handled by JDK-8324089 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19942/files - new: https://git.openjdk.org/jdk/pull/19942/files/ce749f41..646f9230 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19942&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19942&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19942/head:pull/19942 PR: https://git.openjdk.org/jdk/pull/19942 From syan at openjdk.org Wed Jul 3 01:30:35 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Jul 2024 01:30:35 GMT Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3] In-Reply-To: References: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com> Message-ID: On Tue, 2 Jul 2024 20:49:05 GMT, Dean Long wrote: > Why does 8M trigger the OOM Killer, but 1M does not? 8M trigger the OOM killer on some environments, maybe there are some test machines that 8M trigger the OOM exception rather than OOM killer. The intention of change `8M chunks per iteration` to `1M chunks per iteration`, is make sure this testcase throw OOM exception and then [break the memory allocation loop](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java#L88) before jvm process OOM killed by docker container. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2204847751 From dholmes at openjdk.org Wed Jul 3 02:21:21 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Jul 2024 02:21:21 GMT Subject: RFR: 8331385: G1: Prefix HeapRegion helper classes with G1 In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:35:00 GMT, Thomas Schatzl wrote: > Hi all, > > after [JDK-8330694](https://bugs.openjdk.org/browse/JDK-8330694) which renamed HeapRegion to G1HeapRegion, there were a few related helper classes in this CR that were not renamed. > > It's purely mechanical renaming without even further renaming of files etc. > > This change updates them. > > (Fwiw, the "Viewed" checkbox at the top right of the file change helps a lot review this change incrementally) > > Testing: tier1, tier4, tier5 > > Thanks, > Thomas Seems okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19967#pullrequestreview-2155206936 From kbarrett at openjdk.org Wed Jul 3 02:22:28 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 3 Jul 2024 02:22:28 GMT Subject: RFR: 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp In-Reply-To: <03kxq5h91-B_yT-WWrkBGew9-Ncp2ZUvMbfMR64ICV4=.53d2da6f-772e-457c-b813-ea1bfbfff6b0@github.com> References: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> <03kxq5h91-B_yT-WWrkBGew9-Ncp2ZUvMbfMR64ICV4=.53d2da6f-772e-457c-b813-ea1bfbfff6b0@github.com> Message-ID: <8MI-38v_ftretJOUeVPqN-fUCEmZrRJIKRDHk_UeIoA=.3ed3620c-ae05-40fb-ad10-b331ccbaa749@github.com> On Mon, 1 Jul 2024 04:14:13 GMT, Julian Waters wrote: >> Please review this trivial change to the print_method function in >> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE* >> argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning >> is enabled. The change is to replace that 0 with nullptr. >> >> This removes about 10% of the -Wzero-as-null-pointer-constant warnings when >> building with that option. >> >> Testing: mach5 tier1 > > Marked as reviewed by jwaters (Committer). Thanks for reviews @TheShermanTanker , @alexmenkov , and @sspitsyn . ------------- PR Comment: https://git.openjdk.org/jdk/pull/19962#issuecomment-2204917404 From kbarrett at openjdk.org Wed Jul 3 02:22:29 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 3 Jul 2024 02:22:29 GMT Subject: Integrated: 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp In-Reply-To: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> References: <1sdABYuA737KyItb_D4r_SKQBZg84rnQZ2tS8-3WNz4=.5796536e-0785-4169-a01d-0450e5074ee2@github.com> Message-ID: On Sun, 30 Jun 2024 22:15:34 GMT, Kim Barrett wrote: > Please review this trivial change to the print_method function in > test/lib/jdk/test/lib/jvmti/jvmti_common.hpp. It was passing 0 as the FILE* > argument to fflush, triggering -Wzero-as-null-pointer-constant if that warning > is enabled. The change is to replace that 0 with nullptr. > > This removes about 10% of the -Wzero-as-null-pointer-constant warnings when > building with that option. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: f187c92b Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/f187c92befbe63e23b11eb0401e5095c44c24389 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp Reviewed-by: jwaters, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19962 From sspitsyn at openjdk.org Wed Jul 3 03:58:19 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Jul 2024 03:58:19 GMT Subject: RFR: 8269881: SA stack dump fails to include stack trace for SteadyStateThread In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer wrote: > The completely unrelated fix to [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe that the issue with sometimes not being able to get the stack trace of the SteadyStateThread might be due to the thread being active for a short period after being reported as in the Thread.State.BLOCKED state. Once set to that state, the thread still needs to call a native OS API to block the thread so it is truly idle. During this time the thread stack might be inconsistent and not walk-able. The fix is to add a short sleep after the thread has moved to the Thread.State.BLOCKED state to give it a chance to finish blocking. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. This is the most simple solution but not 100% reliable. Looks okay to me. test/lib/jdk/test/lib/apps/LingeredApp.java line 589: > 587: } > 588: > 589: // Wait a short period of time so we can be sure the thread truly is blocked. See JDK-8269881. Nit: Would this be better?: "truly is blocked" => "is truly blocked" ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2155294863 PR Review Comment: https://git.openjdk.org/jdk/pull/19951#discussion_r1663448562 From sspitsyn at openjdk.org Wed Jul 3 04:06:18 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Jul 2024 04:06:18 GMT Subject: RFR: 8313235: TestClhsdbJstackLock.java failed with '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class for LingeredAppWithLock\)$' missing from stdout/stderr In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 22:30:52 GMT, Chris Plummer wrote: > Once the main thread has detected that the spawned thread is in the BLOCKED state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible on the top of the stack, but it is not, so the "waiting to lock" message is missing from the stack trace. > > I think the explanations mentioned in [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) and [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) apply here also. The state of the thread has moved to BLOCKED, but the thread still needs to finish making an OS call to actually become blocked and the thread become idle. During that time we may not be able to get an accurate stack trace. In this case probably SP has not been flushed, so we are not seeing the lockMethod() frame, which should appear at the top of the stack. > > A short delay has been added after all threads have entered the desired state to make sure they have fully reached the desired state and are now idle. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19953#pullrequestreview-2155319208 From kevinw at openjdk.org Wed Jul 3 08:29:40 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 08:29:40 GMT Subject: [jdk23] RFR: 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range Message-ID: <7JorVYHv2FWSlD4ZQ3cEK_jQfKJweCJkH5jaNG_nsFw=.8e697bb4-260f-4ac6-bb86-6f6fb6e03f60@github.com> Clean backport to jdk23 of a simple test update, to try and avoid spurious failures. ------------- Commit messages: - Backport 79a3554e1da604627b3a010dc269c1bd914c79d3 Changes: https://git.openjdk.org/jdk/pull/19999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335124 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19999/head:pull/19999 PR: https://git.openjdk.org/jdk/pull/19999 From kevinw at openjdk.org Wed Jul 3 08:43:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 08:43:19 GMT Subject: RFR: 8322812: Manpage for jcmd is missing JFR.view command [v2] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 22:53:45 GMT, Erik Gahlin wrote: >> Could I have a review of a change to the jcmd man page? >> >> Testing: tier1 >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision: > > - Remove accidentally added file > - Remove fix of typo. It will be handled by JDK-8324089 Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19942#pullrequestreview-2155832194 From thihup at gmail.com Wed Jul 3 10:26:27 2024 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Wed, 3 Jul 2024 07:26:27 -0300 Subject: Proposal: Option to ignore non-existent -javaagent Message-ID: Dear JDK developers, I'd like to propose adding an option that allows the JVM to ignore a non-existent -javaagent instead of aborting. Currently, if a -javaagent is specified but the agent jar file doesn't exist, the JVM aborts with an error. This can cause issues in environments where the same JVM arguments are used across different systems, but not all systems have the agent installed. The proposed option (e.g. -XX:+IgnoreNonExistentJavaAgent) would allow the JVM to continue starting up even if the specified agent jar is not found, simply skipping that agent. This could improve flexibility and ease deployment in heterogeneous environments. Potential considerations: 1. Security implications of silently ignoring a missing agent 2. Logging when an agent is skipped 3. Interaction with other agent-related options I'd appreciate your thoughts on this proposal. Is this something that would be valuable to the community? Are there any concerns or alternative approaches we should consider? Thank you for your time and consideration. Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From egahlin at openjdk.org Wed Jul 3 11:39:22 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 3 Jul 2024 11:39:22 GMT Subject: Integrated: 8322812: Manpage for jcmd is missing JFR.view command In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 14:51:57 GMT, Erik Gahlin wrote: > Could I have a review of a change to the jcmd man page? > > Testing: tier1 > > Thanks > Erik This pull request has now been integrated. Changeset: 350f9c19 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/350f9c1947b0eab3ee233516ceefca1e25de9583 Stats: 49 lines in 1 file changed: 49 ins; 0 del; 0 mod 8322812: Manpage for jcmd is missing JFR.view command Reviewed-by: kevinw, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/19942 From kevinw at openjdk.org Wed Jul 3 12:08:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 12:08:21 GMT Subject: RFR: 8332124: Jcmd processing should accept the "help" sub option as command argument [v5] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 15:21:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to accept "help" as an argument to subcommands. >> >> Testing: >> - [x] Verified running `jcmd 4711 VM.metaspace help` works along with other subcommands. >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Making enabling help more restrictive. Will not accept -help Hi, 1. The JBS issue and PR title need an update. Maybe something like: Jcmd should recognise options that look like requests for help 2. I would encourage recognising "-help" in this change. This is contrary to Thomas' suggestion, and I see the clash with posix style --options, but we already have many many single-minus-prefixed options. This change as I see it is an undocumented attempt to help lost users. If we start a migration to posix-style, much effort will be needed so this clash, which could be fixed then, will seem insignificant. 3. I want to mention the alternative to this change: print the command help whenever showing an error. The downside would be that it can be quite long, and maybe you don't want to see several screens of help when you mistype one option to jcmd JFR.start... I think we should complete what we have here already, but we should note that there are alternatives. 4. sun/tools/jcmd/TestJcmdSubcommandHelp.java The summary at line 28 needs updating, whether you add "-help" or not. Would be great to test "jcmd VM.command -hello" and check it does not show help. I added one and tried it out, will paste it in here somehow. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2205920976 From kevinw at openjdk.org Wed Jul 3 12:16:20 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 12:16:20 GMT Subject: RFR: 8332124: Jcmd processing should accept the "help" sub option as command argument [v5] In-Reply-To: References: Message-ID: <0Xn4dqgQA5ydwS6pFNWIjDShyT6QYnDl8_HMrFo4iC4=.871f1115-a78d-475b-a309-cf8d3975818a@github.com> On Tue, 2 Jul 2024 15:21:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to accept "help" as an argument to subcommands. >> >> Testing: >> - [x] Verified running `jcmd 4711 VM.metaspace help` works along with other subcommands. >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Making enabling help more restrictive. Will not accept -help Additional test possibility. *** orig.txt 2024-07-03 13:08:46.460514793 +0100 --- test/jdk/sun/tools/jcmd/TestJcmdSubcommandHelp.java 2024-07-03 12:50:48.324022729 +0100 *************** *** 39,48 **** --- 39,49 ---- public class TestJcmdSubcommandHelp { private static final String HELP_ONE_DASH = "-h"; private static final String HELP_TWO_DASH = "--help"; private static final String CMD = "VM.metaspace"; + private static final String ILLEGAL = "IllegalArgumentException: Unknown argument"; public static void main(String[] args) throws Exception { // Sanity check with empty input OutputAnalyzer output = JcmdBase.jcmd(); *************** *** 59,68 **** --- 60,72 ---- testIgnoreAdditionalArgs(HELP_ONE_DASH, expectedOutput); testIgnoreAdditionalArgs(HELP_TWO_DASH, expectedOutput); testIgnoreTrailingSpaces(HELP_ONE_DASH, expectedOutput); testIgnoreTrailingSpaces(HELP_TWO_DASH, expectedOutput); + + testSimilarCommand(HELP_ONE_DASH + "ello", ILLEGAL); + testSimilarCommand(HELP_TWO_DASH + "me", ILLEGAL); } private static void testExpectedUsage(String helpOption, String expectedOutput) throws Exception { verifyOutput(new String[] {CMD, helpOption}, expectedOutput, "Expected jcmd to accept '%s' suboption as a command argument and issue the same help output.".formatted(helpOption)); *************** *** 76,93 **** --- 80,114 ---- private static void testIgnoreTrailingSpaces(String helpOption, String expectedOutput) throws Exception { verifyOutput(new String[] {CMD, "%s ".formatted(helpOption)}, expectedOutput, "Expected jcmd to accept '%s' suboption with trailing spaces".formatted(helpOption)); } + private static void testSimilarCommand(String helpOption, String expectedOutput) throws Exception { + verifyOutputContains(new String[] {CMD, helpOption}, expectedOutput, + "Expected jcmd to NOT accept '%s' suboption with trailing content".formatted(helpOption)); + } + private static void verifyOutput(String[] args, String expectedOutput, String errorMessage) throws Exception { OutputAnalyzer output = JcmdBase.jcmd(args); String issuedOutput = output.getOutput(); if (!expectedOutput.equals(issuedOutput)) { System.out.println("Expected output: "); System.out.println(expectedOutput); System.out.println("Issued output: "); System.out.println(issuedOutput); throw new Exception(errorMessage); + } + } + + private static void verifyOutputContains(String[] args, String expectedOutput, String errorMessage) throws Exception { + OutputAnalyzer output = JcmdBase.jcmd(args); + String issuedOutput = output.getOutput(); + if (!issuedOutput.contains(expectedOutput)) { + System.out.println("Expected output: "); + System.out.println(expectedOutput); + System.out.println("Issued output: "); + System.out.println(issuedOutput); + throw new Exception(errorMessage); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2205934378 From duke at openjdk.org Wed Jul 3 14:24:31 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 14:24:31 GMT Subject: RFR: 8297173: usageTicks and totalTicks should be volatile to ensure that different threads get the latest ticks In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 06:28:37 GMT, Poison wrote: > As the title says, add the volatile modifier. @tianshuang Your change (at version dd4599661ab209ef1a77c36be066a2af61304156) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11199#issuecomment-1318340110 From duke at openjdk.org Wed Jul 3 14:24:32 2024 From: duke at openjdk.org (duke) Date: Wed, 3 Jul 2024 14:24:32 GMT Subject: RFR: 8297173: usageTicks and totalTicks should be volatile to ensure that different threads get the latest ticks [v2] In-Reply-To: <__C9hdFdiGwECNQ9NBVry5dNseFyVSlHQSN8GYdlVf8=.65b8af68-5327-42e4-9445-e2237cb38aa7@github.com> References: <__C9hdFdiGwECNQ9NBVry5dNseFyVSlHQSN8GYdlVf8=.65b8af68-5327-42e4-9445-e2237cb38aa7@github.com> Message-ID: On Thu, 17 Nov 2022 09:43:39 GMT, Poison wrote: >> As the title says, add the volatile modifier. > > Poison has updated the pull request incrementally with one additional commit since the last revision: > > 8297173: usageTicks and totalTicks should be volatile @tianshuang Your change (at version f6b19bb0ea59165a59be600f615f0896f18b9f4c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11199#issuecomment-1319829256 From szaldana at openjdk.org Wed Jul 3 14:31:51 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 3 Jul 2024 14:31:51 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v6] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to accept "help" as an argument to subcommands. > > Testing: > - [x] Verified running `jcmd 4711 VM.metaspace help` works along with other subcommands. > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision: - Updating comments - Enabling -help to work as well. Updating test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19776/files - new: https://git.openjdk.org/jdk/pull/19776/files/4e2a4493..56203e57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=04-05 Stats: 41 lines in 3 files changed: 32 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19776/head:pull/19776 PR: https://git.openjdk.org/jdk/pull/19776 From szaldana at openjdk.org Wed Jul 3 14:31:51 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 3 Jul 2024 14:31:51 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v5] In-Reply-To: <0Xn4dqgQA5ydwS6pFNWIjDShyT6QYnDl8_HMrFo4iC4=.871f1115-a78d-475b-a309-cf8d3975818a@github.com> References: <0Xn4dqgQA5ydwS6pFNWIjDShyT6QYnDl8_HMrFo4iC4=.871f1115-a78d-475b-a309-cf8d3975818a@github.com> Message-ID: On Wed, 3 Jul 2024 12:13:34 GMT, Kevin Walls wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Making enabling help more restrictive. Will not accept -help > > Additional test possibility. I copied what you had already, but should have used the OutputAnalyzer "shouldContain" method. > > > *** orig.txt 2024-07-03 13:08:46.460514793 +0100 > --- test/jdk/sun/tools/jcmd/TestJcmdSubcommandHelp.java 2024-07-03 12:50:48.324022729 +0100 > *************** > *** 39,48 **** > --- 39,49 ---- > public class TestJcmdSubcommandHelp { > > private static final String HELP_ONE_DASH = "-h"; > private static final String HELP_TWO_DASH = "--help"; > private static final String CMD = "VM.metaspace"; > + private static final String ILLEGAL = "IllegalArgumentException: Unknown argument"; > > public static void main(String[] args) throws Exception { > > // Sanity check with empty input > OutputAnalyzer output = JcmdBase.jcmd(); > *************** > *** 59,68 **** > --- 60,72 ---- > testIgnoreAdditionalArgs(HELP_ONE_DASH, expectedOutput); > testIgnoreAdditionalArgs(HELP_TWO_DASH, expectedOutput); > > testIgnoreTrailingSpaces(HELP_ONE_DASH, expectedOutput); > testIgnoreTrailingSpaces(HELP_TWO_DASH, expectedOutput); > + > + testSimilarCommand(HELP_ONE_DASH + "ello", ILLEGAL); > + testSimilarCommand(HELP_TWO_DASH + "me", ILLEGAL); > } > > private static void testExpectedUsage(String helpOption, String expectedOutput) throws Exception { > verifyOutput(new String[] {CMD, helpOption}, expectedOutput, > "Expected jcmd to accept '%s' suboption as a command argument and issue the same help output.".formatted(helpOption)); > *************** > *** 76,93 **** > --- 80,114 ---- > private static void testIgnoreTrailingSpaces(String helpOption, String expectedOutput) throws Exception { > verifyOutput(new String[] {CMD, "%s ".formatted(helpOption)}, expectedOutput, > "Expected jcmd to accept '%s' suboption with trailing spaces".formatted(helpOption)); > } > > + private static void testSimilarCommand(String helpOption, String expectedOutput) throws Exception { > + verifyOutputContains(new String[] {CMD, helpOption}, expectedOutput, > + "Expected jcmd to NOT accept '%s' suboption with trailing content".formatted(helpOption)); > + } > + > private static void verifyOutput(String[] args, String expectedOutput, String errorMessage) throws Exception { > OutputAnalyzer output = JcmdBase.jcmd(args); > String issuedOutput = output.getOutput(); > if (!expectedOutput.equals(issuedOutput)) { > ... Hi @kevinjwalls, thanks for taking a look! I made some updates based on your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2206297148 From kevinw at openjdk.org Wed Jul 3 15:21:43 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 15:21:43 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction Message-ID: CmdLine::is_executable() looks wrong, surely an empty line is not executable. With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. DCmd tests all good: make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" ------------- Commit messages: - DiagnosticFramework: CmdLine::is_executable() correction Changes: https://git.openjdk.org/jdk/pull/20006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335610 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20006/head:pull/20006 PR: https://git.openjdk.org/jdk/pull/20006 From kevinw at openjdk.org Wed Jul 3 15:21:43 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 15:21:43 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Noticed this issue while reviewing https://github.com/openjdk/jdk/pull/19776 (but not directly related to that change). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2206509147 From simonis at openjdk.org Wed Jul 3 16:19:31 2024 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 3 Jul 2024 16:19:31 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors Message-ID: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, unrelated class, that class will remain in an error state forever due to [?5.4.3 Resolution](https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3) of the Java Virtual Machine Specification which mandates that "*if an attempt by the Java Virtual Machine to resolve a symbolic reference fails because an error is thrown that is an instance of LinkageError (or a subclass), then subsequent attempts to resolve the reference always fail with the same error that wa s thrown as a result of the initial resolution attempt.*". This means that the `ClassCircularityError` can repeatedly be thrown much later, in user code which is completely unrelated to class file transformation if that code happens to use the same class that failed to resolve a reference during instrumentation. A good example for this scenario are the sporadic `ClassCircularityError` that were seen in user code while using `ConcurrentHashMap`s caused by a change in the popular ByteBuddy library (see [ByteBuddy #1666 for more details](https://github.com/raphw/byte-buddy/issues/1666)). I'd therefor like to propose to add an `@apiNote` to j.l.i.ClassFileTransformer which makes users of the API aware of these potential issues: * @apiNote * If the invocation of {@link #transform transform()} for a class C * directly or transitively requires loading or resolving the same class C, * an error is thrown that is an instance of {@link LinkageError} (or a subclass). * Transforming core JDK classes or using libraries which depend on core JDK classes * during transformation increases the risk for such errors. If the {@link LinkageError} * occurs during reference resolution (see section 5.4.3 Resolution of The * Java Virtual Machine Specification) for a class D, the * corresponding reference resolution in class D will always fail * with the same error. This means that a {@link LinkageError} triggered during * transformation of C in a class D not directly related to * C can repeatedly occur later in arbitrary user code which uses class * D. Please feel free to wordsmith the suggested `@apiNote` text :) ------------- Commit messages: - 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors Changes: https://git.openjdk.org/jdk/pull/20011/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335619 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20011/head:pull/20011 PR: https://git.openjdk.org/jdk/pull/20011 From mgronlun at openjdk.org Wed Jul 3 16:31:26 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 3 Jul 2024 16:31:26 GMT Subject: RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 12:05:43 GMT, Erik Gahlin wrote: > Could I have a review of a typo for JFR.start and JFR.dump? > > Testing: tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20003#pullrequestreview-2156282430 From egahlin at openjdk.org Wed Jul 3 16:31:26 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 3 Jul 2024 16:31:26 GMT Subject: RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Message-ID: Could I have a review of a typo for JFR.start and JFR.dump? Testing: tier1 Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324089 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20003/head:pull/20003 PR: https://git.openjdk.org/jdk/pull/20003 From kevinw at openjdk.org Wed Jul 3 16:32:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 16:32:27 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v6] In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 14:31:51 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision: > > - Updating comments > - Enabling -help to work as well. Updating test cases One more thing from me, as as_string() uses the ResourceArea, it probably makes sense to move the ResourceMark at line 412 up to line 403. OR, avoid the allocation, we are definitely just reading the characters, so we could use: char *rest = (char*) args.base(); (strtok_r wants a non-const char*) Then OK great, done. If you are making that update and wanted to get the .cpp file comment at line 403 on just two lines, and in the test if you wanted to call the "-h" something other than "POSIX", those would not be bad final updates from my point of view. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2206753142 From kevinw at openjdk.org Wed Jul 3 17:02:20 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Jul 2024 17:02:20 GMT Subject: RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 12:05:43 GMT, Erik Gahlin wrote: > Could I have a review of a typo for JFR.start and JFR.dump? > > Testing: tier1 > > Thanks > Erik Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20003#pullrequestreview-2156954921 From liach at openjdk.org Wed Jul 3 19:49:20 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Jul 2024 19:49:20 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: <9HTCZTIxu5phf4CYKR0UbFwddwlXrrc5xIClHy2XtY0=.6694d589-a610-4d48-a3c4-01c0c3517503@github.com> On Wed, 3 Jul 2024 16:14:31 GMT, Volker Simonis wrote: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 169: > 167: * Transforming core JDK classes or using libraries which depend on core JDK classes > 168: * during transformation increases the risk for such errors. If the {@link LinkageError} > 169: * occurs during reference resolution (see section 5.4.3 Resolution of The Suggestion: * occurs during reference resolution (see section {@jvms 5.4.3} Resolution of The Other stylistic note: we can replace `C` with `{@code C}`, which is shorter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1664674662 From duke at openjdk.org Thu Jul 4 01:48:30 2024 From: duke at openjdk.org (duke) Date: Thu, 4 Jul 2024 01:48:30 GMT Subject: Withdrawn: 8176520: Improve the accuracy of the instance size in hprof heap dumps In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 22:16:02 GMT, Alex Menkov wrote: > The fix updates heap dumpers to report correct instance size value for HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance fields) > > Testing: tier1, tier2, tier5-svc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17855 From dholmes at openjdk.org Thu Jul 4 05:23:20 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Jul 2024 05:23:20 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: <6j4-za3A4wGla_BnMHy_dwZGEZwnO9rhYbYirpkF7uM=.6a2d382b-7aa9-4c53-a37b-db2af3e4d3f9@github.com> On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Can a line ever be empty? If so we should have a test case for that. ------------- PR Review: https://git.openjdk.org/jdk/pull/20006#pullrequestreview-2157983442 From stuefe at openjdk.org Thu Jul 4 06:17:19 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Jul 2024 06:17:19 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: <4hKoi7ngXIlRNVs7ULFIKyPLBIAKZvzxOk4Kibzdp7w=.3acf472f-c5ee-465c-8142-5e9074f70db0@github.com> On Wed, 3 Jul 2024 16:14:31 GMT, Volker Simonis wrote: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... Small nit, otherwise ok. As usual, excellent bug description. src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 168: > 166: * an error is thrown that is an instance of {@link LinkageError} (or a subclass). > 167: * Transforming core JDK classes or using libraries which depend on core JDK classes > 168: * during transformation increases the risk for such errors. If the {@link LinkageError} small nit Suggestion: * Transforming core JDK classes or using libraries that depend on core JDK classes * during transformation increases the risk of such errors. If the {@link LinkageError} ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20011#pullrequestreview-2158057659 PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1665180393 From stuefe at openjdk.org Thu Jul 4 06:40:21 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Jul 2024 06:40:21 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v6] In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 14:31:51 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision: > > - Updating comments > - Enabling -help to work as well. Updating test cases Marked as reviewed by stuefe (Reviewer). > OR, avoid the allocation, we are definitely just reading the characters, so we could use: char _rest = (char_) args.base(); (strtok_r wants a non-const char*) > > Then OK great, done. > No, please don't do that. It is bad practice - don't get in the habit of casting away constness unless you are sure you know what happens. strtok modifies the string, that is why it needs write access, and it would destroy the string, making it unusable for the case when we have *not* a help command. Other than that, it looks okay for me and I will approve it in this form. However, if you have the time, you could rewrite the reorder function to not use strtok but to do the scanning yourself. - with a pointer pointing to the start of arguments - walk pointer for as long as there are spaces, or until \0 - then, use strncmp (notice the n) to check for the commands - then you are done. No need to copy the string, no need for strtok to filet the string in its whole glory just for most of it to be ignored later. Cheers, Thomas src/hotspot/share/services/diagnosticFramework.cpp line 427: > 425: args.print("%s", line.args_addr()); > 426: char *rest = args.as_string(); > 427: char *token = strtok_r(rest, " ", &rest); Nit, please use char* V not char *V, the former is much more common in hotspot. ------------- PR Review: https://git.openjdk.org/jdk/pull/19776#pullrequestreview-2158073557 PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2208225831 PR Review Comment: https://git.openjdk.org/jdk/pull/19776#discussion_r1665190517 From kevinw at openjdk.org Thu Jul 4 09:02:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 09:02:19 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: <6j4-za3A4wGla_BnMHy_dwZGEZwnO9rhYbYirpkF7uM=.6a2d382b-7aa9-4c53-a37b-db2af3e4d3f9@github.com> References: <6j4-za3A4wGla_BnMHy_dwZGEZwnO9rhYbYirpkF7uM=.6a2d382b-7aa9-4c53-a37b-db2af3e4d3f9@github.com> Message-ID: On Thu, 4 Jul 2024 05:20:38 GMT, David Holmes wrote: > Can a line ever be empty? No it can't. Runing "jcmd PID" becomes "help", and giving empty quotes as the command like jcmd PID "" does pass an empty string to parse_and_execute(), but the DCmdIter in there will never find anything to iterate (nor with multiple "" or with " "). bash-4.2$ jcmd 18851 "" 18851: Command executed successfully The CmdLine is the thing that would be returned by DCmdIter, and we don't create empty ones (as things stand today). So this change should be harmless but correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2208465886 From dholmes at openjdk.org Thu Jul 4 09:27:18 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Jul 2024 09:27:18 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" But if it can't be empty can we not just assert that and get rid of the is_empty check from is_executable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2208516938 From egahlin at openjdk.org Thu Jul 4 10:06:23 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Jul 2024 10:06:23 GMT Subject: Integrated: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 12:05:43 GMT, Erik Gahlin wrote: > Could I have a review of a typo for JFR.start and JFR.dump? > > Testing: tier1 > > Thanks > Erik This pull request has now been integrated. Changeset: 0bb9c762 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/0bb9c76288b5f63fe965c3276bb566cef5f51c50 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Reviewed-by: mgronlun, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/20003 From simonis at openjdk.org Thu Jul 4 10:42:21 2024 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 4 Jul 2024 10:42:21 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors In-Reply-To: <4hKoi7ngXIlRNVs7ULFIKyPLBIAKZvzxOk4Kibzdp7w=.3acf472f-c5ee-465c-8142-5e9074f70db0@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> <4hKoi7ngXIlRNVs7ULFIKyPLBIAKZvzxOk4Kibzdp7w=.3acf472f-c5ee-465c-8142-5e9074f70db0@github.com> Message-ID: On Thu, 4 Jul 2024 06:14:35 GMT, Thomas Stuefe wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 168: > >> 166: * an error is thrown that is an instance of {@link LinkageError} (or a subclass). >> 167: * Transforming core JDK classes or using libraries which depend on core JDK classes >> 168: * during transformation increases the risk for such errors. If the {@link LinkageError} > > small nit > Suggestion: > > * Transforming core JDK classes or using libraries that depend on core JDK classes > * during transformation increases the risk of such errors. If the {@link LinkageError} Thanks for your review (and the kind words :) @tstuefe I've updated the PR based on your suggestions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1665515920 From simonis at openjdk.org Thu Jul 4 10:42:21 2024 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 4 Jul 2024 10:42:21 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors In-Reply-To: <9HTCZTIxu5phf4CYKR0UbFwddwlXrrc5xIClHy2XtY0=.6694d589-a610-4d48-a3c4-01c0c3517503@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> <9HTCZTIxu5phf4CYKR0UbFwddwlXrrc5xIClHy2XtY0=.6694d589-a610-4d48-a3c4-01c0c3517503@github.com> Message-ID: On Wed, 3 Jul 2024 19:44:36 GMT, Chen Liang wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 169: > >> 167: * Transforming core JDK classes or using libraries which depend on core JDK classes >> 168: * during transformation increases the risk for such errors. If the {@link LinkageError} >> 169: * occurs during reference resolution (see section 5.4.3 Resolution of The > > Suggestion: > > * occurs during reference resolution (see section {@jvms 5.4.3} Resolution of The > > Other stylistic note: we can replace `C` with `{@code C}`, which is shorter. Thanks for your suggestion @liach . I didn't knew about the `@jvms` tag which is quite handy. I've also updated the other reference to the JVMS above the new `@apiNote` which didn't used the tag either (and was wrong because the JVMS sections have changed since Java 5 :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1665513865 From simonis at openjdk.org Thu Jul 4 10:49:47 2024 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 4 Jul 2024 10:49:47 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Fixed text based on reviewer comments. Also added a '@jvms' tag to another reference to the JVMS and fixed its section number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20011/files - new: https://git.openjdk.org/jdk/pull/20011/files/69b06d4b..080999e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20011/head:pull/20011 PR: https://git.openjdk.org/jdk/pull/20011 From stuefe at openjdk.org Thu Jul 4 10:49:47 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Jul 2024 10:49:47 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Thu, 4 Jul 2024 10:46:37 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Fixed text based on reviewer comments. Also added a '@jvms' tag to another reference to the JVMS and fixed its section number LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20011#pullrequestreview-2158619145 From simonis at openjdk.org Thu Jul 4 10:57:20 2024 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 4 Jul 2024 10:57:20 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Thu, 4 Jul 2024 10:49:47 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Fixed text based on reviewer comments. Also added a '@jvms' tag to another reference to the JVMS and fixed its section number Notice that according to the [CSR FAQ](https://wiki.openjdk.org/display/csr/CSR+FAQs), I don't think that this change requires a CSR because it is not changing the specification but merely describes the actual behavior in some more detail: > Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed? A: *A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review.* ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2208685235 From kevinw at openjdk.org Thu Jul 4 11:12:40 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 11:12:40 GMT Subject: RFR: 8335684: ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Message-ID: There are two similarly names tests. Recently: JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. Also removing an old comment about a Solaris issue. ------------- Commit messages: - 8335684: ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Changes: https://git.openjdk.org/jdk/pull/20025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335684 Stats: 12 lines in 1 file changed: 2 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20025/head:pull/20025 PR: https://git.openjdk.org/jdk/pull/20025 From egahlin at openjdk.org Thu Jul 4 11:41:29 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Jul 2024 11:41:29 GMT Subject: [jdk23] RFR: 8322812: Manpage for jcmd is missing JFR.view command Message-ID: <9JmeyY2ChWrqlu8LzelbpMBHDNbqtLyvg7ckk_itlvM=.0721a7c8-e44a-45a1-8347-79c0e76f2661@github.com> 8322812: Manpage for jcmd is missing JFR.view command ------------- Commit messages: - Backport 350f9c1947b0eab3ee233516ceefca1e25de9583 Changes: https://git.openjdk.org/jdk/pull/20028/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20028&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322812 Stats: 49 lines in 1 file changed: 49 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20028/head:pull/20028 PR: https://git.openjdk.org/jdk/pull/20028 From mgronlun at openjdk.org Thu Jul 4 11:41:29 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Jul 2024 11:41:29 GMT Subject: [jdk23] RFR: 8322812: Manpage for jcmd is missing JFR.view command In-Reply-To: <9JmeyY2ChWrqlu8LzelbpMBHDNbqtLyvg7ckk_itlvM=.0721a7c8-e44a-45a1-8347-79c0e76f2661@github.com> References: <9JmeyY2ChWrqlu8LzelbpMBHDNbqtLyvg7ckk_itlvM=.0721a7c8-e44a-45a1-8347-79c0e76f2661@github.com> Message-ID: On Thu, 4 Jul 2024 10:51:48 GMT, Erik Gahlin wrote: > 8322812: Manpage for jcmd is missing JFR.view command Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20028#pullrequestreview-2158707721 From egahlin at openjdk.org Thu Jul 4 11:41:42 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Jul 2024 11:41:42 GMT Subject: [jdk23] RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Message-ID: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) ------------- Commit messages: - Backport 0bb9c76288b5f63fe965c3276bb566cef5f51c50 Changes: https://git.openjdk.org/jdk/pull/20030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324089 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20030/head:pull/20030 PR: https://git.openjdk.org/jdk/pull/20030 From mgronlun at openjdk.org Thu Jul 4 11:41:42 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 4 Jul 2024 11:41:42 GMT Subject: [jdk23] RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:54:22 GMT, Erik Gahlin wrote: > 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20030#pullrequestreview-2158706543 From liach at openjdk.org Thu Jul 4 11:49:20 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Jul 2024 11:49:20 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Thu, 4 Jul 2024 10:49:47 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Fixed text based on reviewer comments. Also added a '@jvms' tag to another reference to the JVMS and fixed its section number Looks good. We can always file a retroactive CSR if people find this clarification worth of archiving/recording. ------------- Marked as reviewed by liach (Committer). PR Review: https://git.openjdk.org/jdk/pull/20011#pullrequestreview-2158738957 From kbarrett at openjdk.org Thu Jul 4 12:20:27 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 4 Jul 2024 12:20:27 GMT Subject: RFR: 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests Message-ID: Please review this change to some jvmti tests, which were calling fflush with an argument of 0. Most of these are in C++ code, where we change them to use nullptr as the argument. A couple are in C, where we change them to use NULL. This removes a bunch of -Wzero-as-null-pointer-constant when building with that enabled. Testing: mach5 tier1 ------------- Commit messages: - fix fflush calls in hotspot code Changes: https://git.openjdk.org/jdk/pull/20032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335688 Stats: 175 lines in 25 files changed: 0 ins; 0 del; 175 mod Patch: https://git.openjdk.org/jdk/pull/20032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20032/head:pull/20032 PR: https://git.openjdk.org/jdk/pull/20032 From kevinw at openjdk.org Thu Jul 4 13:18:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 13:18:19 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:24:52 GMT, David Holmes wrote: > But if it can't be empty can we not just assert that and get rid of the is_empty check from is_executable? Yes, we might be able to do that. I was going for just the obvious logic correction, because it's distracting to read through things that look wrong. Looking at it again today I'm still not sure if we should restrict it so a CmdLine can never be empty in some future usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2208968382 From jsjolen at openjdk.org Thu Jul 4 13:23:43 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Jul 2024 13:23:43 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index Message-ID: Hi, Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. This opens up for a few new design choices: - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. - Do you have a very large one? Use an `uint64_t`. The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. // Old mid = ((max + min) / 2); // New mid = min + ((max - min) / 2); Some semi-rigorous thinking: min \in [0, len) max \in [0, len) min <= max max - min / 2 \in [0, len/2) Maximizing min and max => len + 0 Maximizing max, minimizing min => len/2 Minimizing max, maximizing min => max = min => min // Proof that they're identical when m, h, l \in N (1) m = l + (h - l) / 2 <=> 2m = 2l + h - l = h + l (2) m = (h + l) / 2 <=> 2m = h + l (1) = (2) QED ------------- Commit messages: - Fix spelling and actually include the growableArray is it used in cpp file - Move - Handle unhandled oops - Make GrowableArray receive an Index type optionally Changes: https://git.openjdk.org/jdk/pull/20031/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20031&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335701 Stats: 262 lines in 32 files changed: 19 ins; 25 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/20031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20031/head:pull/20031 PR: https://git.openjdk.org/jdk/pull/20031 From jsjolen at openjdk.org Thu Jul 4 13:35:36 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Jul 2024 13:35:36 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v2] In-Reply-To: References: Message-ID: > Hi, > > Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. > > This opens up for a few new design choices: > > - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. > - Do you have a very large one? Use an `uint64_t`. > > The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. > > One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. > > > > // Old > mid = ((max + min) / 2); > // New > mid = min + ((max - min) / 2); > > Some semi-rigorous thinking: > min \in [0, len) > max \in [0, len) > min <= max > max - min / 2 \in [0, len/2) > Maximizing min and max => len + 0 > Maximizing max, minimizing min => len/2 > Minimizing max, maximizing min => max = min => min > > > // Proof that they're identical when m, h, l \in N > (1) m = l + (h - l) / 2 <=> > 2m = 2l + h - l = h + l > > (2) m = (h + l) / 2 <=> > 2m = h + l > (1) = (2) > QED Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Attempt at fixing GA VMStruct ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20031/files - new: https://git.openjdk.org/jdk/pull/20031/files/7407a151..b5a87422 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20031&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20031&range=00-01 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20031/head:pull/20031 PR: https://git.openjdk.org/jdk/pull/20031 From jsjolen at openjdk.org Thu Jul 4 13:41:17 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Jul 2024 13:41:17 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 13:35:36 GMT, Johan Sj?len wrote: >> Hi, >> >> Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. >> >> This opens up for a few new design choices: >> >> - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. >> - Do you have a very large one? Use an `uint64_t`. >> >> The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. >> >> One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. >> >> >> >> // Old >> mid = ((max + min) / 2); >> // New >> mid = min + ((max - min) / 2); >> >> Some semi-rigorous thinking: >> min \in [0, len) >> max \in [0, len) >> min <= max >> max - min / 2 \in [0, len/2) >> Maximizing min and max => len + 0 >> Maximizing max, minimizing min => len/2 >> Minimizing max, maximizing min => max = min => min >> >> >> // Proof that they're identical when m, h, l \in N >> (1) m = l + (h - l) / 2 <=> >> 2m = 2l + h - l = h + l >> >> (2) m = (h + l) / 2 <=> >> 2m = h + l >> (1) = (2) >> QED > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Attempt at fixing GA VMStruct Always fun to grapple with vmStructs, moving this back to draft. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20031#issuecomment-2209022728 From szaldana at openjdk.org Thu Jul 4 14:43:49 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 4 Jul 2024 14:43:49 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v7] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles 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 12 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8332124 - Updates based on feedback. Moving resource mark, updating commets and test - Updating comments - Enabling -help to work as well. Updating test cases - Making enabling help more restrictive. Will not accept -help - Enabling only -h or --help. Also modifying test case - Updating copyright header - Modifying usage to --help and -help. Updated ensuing test case to test both - Updating copyright headers - Merge branch 'openjdk:master' into JDK-8332124 - ... and 2 more: https://git.openjdk.org/jdk/compare/b88504b2...6b52c091 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19776/files - new: https://git.openjdk.org/jdk/pull/19776/files/56203e57..6b52c091 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19776&range=05-06 Stats: 16108 lines in 491 files changed: 10293 ins; 3852 del; 1963 mod Patch: https://git.openjdk.org/jdk/pull/19776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19776/head:pull/19776 PR: https://git.openjdk.org/jdk/pull/19776 From kevinw at openjdk.org Thu Jul 4 14:47:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 14:47:27 GMT Subject: RFR: 8207908: JMXStatusTest.java fails assertion intermittently Message-ID: Test failure, reproducible running batches of tests at the same time on the same machine. The use of "jcmd TestApp ..." gathers more output that the test wants. Using the PID to match only the wanted process, my batches of 25 tests at the same time run in parallel without failure. ------------- Commit messages: - oops - 8207908: JMXStatusTest.java fails assertion intermittently - DiagnosticFramework: CmdLine::is_executable() correction Changes: https://git.openjdk.org/jdk/pull/20037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8207908 Stats: 9 lines in 2 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20037/head:pull/20037 PR: https://git.openjdk.org/jdk/pull/20037 From kevinw at openjdk.org Thu Jul 4 15:05:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 Jul 2024 15:05:21 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v7] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:43:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles 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 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8332124 > - Updates based on feedback. Moving resource mark, updating commets and test > - Updating comments > - Enabling -help to work as well. Updating test cases > - Making enabling help more restrictive. Will not accept -help > - Enabling only -h or --help. Also modifying test case > - Updating copyright header > - Modifying usage to --help and -help. Updated ensuing test case to test both > - Updating copyright headers > - Merge branch 'openjdk:master' into JDK-8332124 > - ... and 2 more: https://git.openjdk.org/jdk/compare/71afd15b...6b52c091 Looks good to me, I think it's done, thanks for you patience. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19776#pullrequestreview-2159124074 From duke at openjdk.org Thu Jul 4 18:15:22 2024 From: duke at openjdk.org (duke) Date: Thu, 4 Jul 2024 18:15:22 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v7] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:43:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles 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 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8332124 > - Updates based on feedback. Moving resource mark, updating commets and test > - Updating comments > - Enabling -help to work as well. Updating test cases > - Making enabling help more restrictive. Will not accept -help > - Enabling only -h or --help. Also modifying test case > - Updating copyright header > - Modifying usage to --help and -help. Updated ensuing test case to test both > - Updating copyright headers > - Merge branch 'openjdk:master' into JDK-8332124 > - ... and 2 more: https://git.openjdk.org/jdk/compare/2a3c2b86...6b52c091 @SoniaZaldana Your change (at version 6b52c0916a66396a910956bf35659429f807f44a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2209425090 From szaldana at openjdk.org Thu Jul 4 18:15:22 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 4 Jul 2024 18:15:22 GMT Subject: RFR: 8332124: Jcmd should recognise options that look like requests for help [v6] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 06:36:41 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision: >> >> - Updating comments >> - Enabling -help to work as well. Updating test cases > >> OR, avoid the allocation, we are definitely just reading the characters, so we could use: char _rest = (char_) args.base(); (strtok_r wants a non-const char*) >> >> Then OK great, done. >> > > No, please don't do that. It is bad practice - don't get in the habit of casting away constness unless you are sure you know what happens. strtok modifies the string, that is why it needs write access, and it would destroy the string, making it unusable for the case when we have *not* a help command. > > Other than that, it looks okay for me and I will approve it in this form. However, if you have the time, you could rewrite the reorder function to not use strtok but to do the scanning yourself. > > - with a pointer pointing to the start of arguments > - walk pointer for as long as there are spaces, or until \0 > - then, use strncmp (notice the n) to check for the commands > - then you are done. No need to copy the string, no need for strtok to filet the string in its whole glory just for most of it to be ignored later. > > Cheers, Thomas Thank you both for the reviews! @tstuefe @kevinjwalls ------------- PR Comment: https://git.openjdk.org/jdk/pull/19776#issuecomment-2209425133 From dholmes at openjdk.org Thu Jul 4 23:11:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Jul 2024 23:11:19 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" My concern is that the logic was wrong and so you fixed it, but this then screams out for a test that would have detected the error, but you can't write a test because the line can never be empty, so that becomes an invariant rather than a runtime check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2209631591 From duke at openjdk.org Fri Jul 5 03:25:29 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 03:25:29 GMT Subject: Withdrawn: 8329204: Diagnostic command for zeroing unused parts of the heap In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 17:24:34 GMT, Volker Simonis wrote: > Diagnostic command for zeroing unused parts of the heap > > I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused parts of the Metaspace and/or CodeCache. > > Currently `System.zero_unused_memory` triggers a full GC and afterwards zeros unused parts of the heap. Zeroing can help snapshotting technologies like [CRIU][1] or [Firecracker][2] to shrink the snapshot size of VMs/containers with running JVM processes because pages which only contain zero bytes can be easily removed from the image by making the image *sparse* (e.g. with [`fallocate -p`][3]). > > Notice that uncommitting unused heap parts in the JVM doesn't help in the context of virtualization (e.g. KVM/Firecracker) because from the host perspective they are still dirty and can't be easily removed from the snapshot image because they usually contain some non-zero data. More details can be found in my FOSDEM talk ["Zeroing and the semantic gap between host and guest"][4]. > > Furthermore, removing pages which only contain zero bytes (i.e. "empty pages") from a snapshot image not only decreases the image size but also speeds up the restore process because empty pages don't have to be read from the image file but will be populated by the kernel zero page first until they are used for the first time. This also decreases the initial memory footprint of a restored process. > > An additional argument for memory zeroing is security. By zeroing unused heap parts, we can make sure that secrets contained in unreferenced Java objects are deleted. Something that's currently impossibly to achieve from Java because even if a Java program zeroes out arrays with sensitive data after usage, it can never guarantee that the corresponding object hasn't already been moved by the GC and an old, unreferenced copy of that data still exists somewhere in the heap. > > A prototype implementation for this proposal for Serial, Parallel, G1 and Shenandoah GC is available in the linked pull request. > > [1]: https://criu.org > [2]: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md > [3]: https://man7.org/linux/man-pages/man1/fallocate.1.html > [4]: https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic-gap-between-host-and-guest/ This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18521 From stuefe at openjdk.org Fri Jul 5 04:50:52 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 5 Jul 2024 04:50:52 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 Message-ID: The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. ------------- Commit messages: - JDK-8335643-serviceability-dcmd-vm-tests-fail-for-ZGC-after-JDK-8322475 Changes: https://git.openjdk.org/jdk/pull/20034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335643 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20034/head:pull/20034 PR: https://git.openjdk.org/jdk/pull/20034 From szaldana at openjdk.org Fri Jul 5 04:51:29 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 5 Jul 2024 04:51:29 GMT Subject: Integrated: 8332124: Jcmd should recognise options that look like requests for help In-Reply-To: References: Message-ID: On Tue, 18 Jun 2024 19:48:20 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8332124](https://bugs.openjdk.org/browse/JDK-8332124) enabling jcmd to recognize options that look like help. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia This pull request has now been integrated. Changeset: b9d8056d Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/b9d8056d5c1528198ad373f9b4a09547e2fcabd6 Stats: 151 lines in 3 files changed: 149 ins; 0 del; 2 mod 8332124: Jcmd should recognise options that look like requests for help Reviewed-by: kevinw, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/19776 From sgehwolf at openjdk.org Fri Jul 5 06:23:20 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 06:23:20 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 In-Reply-To: References: Message-ID: <1Wh7UDVzfiCd_otVUhFyZ05gnNUfKDR0aLyrZkzY0NI=.2c092ea8-41fa-4ad9-8579-12865977471d@github.com> On Thu, 4 Jul 2024 12:57:09 GMT, Thomas Stuefe wrote: > The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. @tstuefe Please also remove the problem list entry. See the error from the skara bot. Thanks! ------------- PR Review: https://git.openjdk.org/jdk/pull/20034#pullrequestreview-2160006454 From tschatzl at openjdk.org Fri Jul 5 07:21:27 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Jul 2024 07:21:27 GMT Subject: RFR: 8331385: G1: Prefix HeapRegion helper classes with G1 In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 10:21:35 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> after [JDK-8330694](https://bugs.openjdk.org/browse/JDK-8330694) which renamed HeapRegion to G1HeapRegion, there were a few related helper classes in this CR that were not renamed. >> >> It's purely mechanical renaming without even further renaming of files etc. >> >> This change updates them. >> >> (Fwiw, the "Viewed" checkbox at the top right of the file change helps a lot review this change incrementally) >> >> Testing: tier1, tier4, tier5 >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @dholmes-ora for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19967#issuecomment-2210331294 From tschatzl at openjdk.org Fri Jul 5 07:21:29 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Jul 2024 07:21:29 GMT Subject: Integrated: 8331385: G1: Prefix HeapRegion helper classes with G1 In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:35:00 GMT, Thomas Schatzl wrote: > Hi all, > > after [JDK-8330694](https://bugs.openjdk.org/browse/JDK-8330694) which renamed HeapRegion to G1HeapRegion, there were a few related helper classes in this CR that were not renamed. > > It's purely mechanical renaming without even further renaming of files etc. > > This change updates them. > > (Fwiw, the "Viewed" checkbox at the top right of the file change helps a lot review this change incrementally) > > Testing: tier1, tier4, tier5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 4ec1ae10 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/4ec1ae109710aa150e27acf5706475d335c4655c Stats: 887 lines in 68 files changed: 163 ins; 165 del; 559 mod 8331385: G1: Prefix HeapRegion helper classes with G1 Reviewed-by: ayang, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/19967 From simonis at openjdk.org Fri Jul 5 07:31:25 2024 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 5 Jul 2024 07:31:25 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Thu, 4 Jul 2024 10:49:47 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Fixed text based on reviewer comments. Also added a '@jvms' tag to another reference to the JVMS and fixed its section number @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? Thank you and best regards, Volker ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2210345568 From jwaters at openjdk.org Fri Jul 5 07:53:19 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 5 Jul 2024 07:53:19 GMT Subject: RFR: 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 12:15:09 GMT, Kim Barrett wrote: > Please review this change to some jvmti tests, which were calling fflush with > an argument of 0. Most of these are in C++ code, where we change them to use > nullptr as the argument. A couple are in C, where we change them to use NULL. > This removes a bunch of -Wzero-as-null-pointer-constant when building with > that enabled. > > Testing: mach5 tier1 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20032#pullrequestreview-2160159717 From stuefe at openjdk.org Fri Jul 5 08:49:18 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 5 Jul 2024 08:49:18 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 In-Reply-To: <1Wh7UDVzfiCd_otVUhFyZ05gnNUfKDR0aLyrZkzY0NI=.2c092ea8-41fa-4ad9-8579-12865977471d@github.com> References: <1Wh7UDVzfiCd_otVUhFyZ05gnNUfKDR0aLyrZkzY0NI=.2c092ea8-41fa-4ad9-8579-12865977471d@github.com> Message-ID: On Fri, 5 Jul 2024 06:20:27 GMT, Severin Gehwolf wrote: > @tstuefe Please also remove the problem list entry. See the error from the skara bot. Thanks! Oh, Skara tells me this now? Or did I never notice :) In any case that's cool. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20034#issuecomment-2210464002 From stuefe at openjdk.org Fri Jul 5 08:53:30 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 5 Jul 2024 08:53:30 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v2] In-Reply-To: References: Message-ID: <40gsnDHHv1Th1GFNO5Z7rC2M91XjyvVZiatBfB2Hn1E=.63dc2fd8-2633-4145-97d9-01dcefebd619@github.com> > The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: problemlist ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20034/files - new: https://git.openjdk.org/jdk/pull/20034/files/5d89a936..50a73e14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20034&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20034/head:pull/20034 PR: https://git.openjdk.org/jdk/pull/20034 From duke at openjdk.org Fri Jul 5 09:27:48 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Fri, 5 Jul 2024 09:27:48 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread Message-ID: This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 if (getMethod().getName().asString().equals("wait") && getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". I confirmed that the lock information is correctly printed with this fix. I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. Would anyone review this change, please? ------------- Commit messages: - 8335743: jhsdb jstack cannot print some information on the waiting thread Changes: https://git.openjdk.org/jdk/pull/20049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335743 Stats: 24 lines in 4 files changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20049/head:pull/20049 PR: https://git.openjdk.org/jdk/pull/20049 From egahlin at openjdk.org Fri Jul 5 10:01:21 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 5 Jul 2024 10:01:21 GMT Subject: [jdk23] Integrated: 8322812: Manpage for jcmd is missing JFR.view command In-Reply-To: <9JmeyY2ChWrqlu8LzelbpMBHDNbqtLyvg7ckk_itlvM=.0721a7c8-e44a-45a1-8347-79c0e76f2661@github.com> References: <9JmeyY2ChWrqlu8LzelbpMBHDNbqtLyvg7ckk_itlvM=.0721a7c8-e44a-45a1-8347-79c0e76f2661@github.com> Message-ID: On Thu, 4 Jul 2024 10:51:48 GMT, Erik Gahlin wrote: > 8322812: Manpage for jcmd is missing JFR.view command This pull request has now been integrated. Changeset: 10b28bab Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/10b28babe53821fcdeef3a1aa0712feb7cd67529 Stats: 49 lines in 1 file changed: 49 ins; 0 del; 0 mod 8322812: Manpage for jcmd is missing JFR.view command Reviewed-by: mgronlun Backport-of: 350f9c1947b0eab3ee233516ceefca1e25de9583 ------------- PR: https://git.openjdk.org/jdk/pull/20028 From sgehwolf at openjdk.org Fri Jul 5 10:03:19 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 10:03:19 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v2] In-Reply-To: <40gsnDHHv1Th1GFNO5Z7rC2M91XjyvVZiatBfB2Hn1E=.63dc2fd8-2633-4145-97d9-01dcefebd619@github.com> References: <40gsnDHHv1Th1GFNO5Z7rC2M91XjyvVZiatBfB2Hn1E=.63dc2fd8-2633-4145-97d9-01dcefebd619@github.com> Message-ID: On Fri, 5 Jul 2024 08:53:30 GMT, Thomas Stuefe wrote: >> The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > problemlist Seems fine to me. Apparently also in `ProblemList-generational-zgc.txt`, which needs to remove those lines. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20034#pullrequestreview-2160393678 Changes requested by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20034#pullrequestreview-2160395464 From stuefe at openjdk.org Fri Jul 5 10:56:37 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 5 Jul 2024 10:56:37 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v3] In-Reply-To: References: Message-ID: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> > The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: problemlist ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20034/files - new: https://git.openjdk.org/jdk/pull/20034/files/50a73e14..7cbeb260 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20034&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20034&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20034/head:pull/20034 PR: https://git.openjdk.org/jdk/pull/20034 From egahlin at openjdk.org Fri Jul 5 10:56:24 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 5 Jul 2024 10:56:24 GMT Subject: [jdk23] Integrated: 8324089: Fix typo in the manual page for "jcmd" (man jcmd) In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:54:22 GMT, Erik Gahlin wrote: > 8324089: Fix typo in the manual page for "jcmd" (man jcmd) This pull request has now been integrated. Changeset: 90d5b5b4 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/90d5b5b4c497ac99d0e2ade689b6459fffea3e2a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Reviewed-by: mgronlun Backport-of: 0bb9c76288b5f63fe965c3276bb566cef5f51c50 ------------- PR: https://git.openjdk.org/jdk/pull/20030 From sgehwolf at openjdk.org Fri Jul 5 11:19:41 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 11:19:41 GMT Subject: RFR: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file Message-ID: Trivial comment only change in a test. Please review! Thanks! ------------- Commit messages: - 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file Changes: https://git.openjdk.org/jdk/pull/20051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335775 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20051.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20051/head:pull/20051 PR: https://git.openjdk.org/jdk/pull/20051 From gdams at openjdk.org Fri Jul 5 11:22:18 2024 From: gdams at openjdk.org (George Adams) Date: Fri, 5 Jul 2024 11:22:18 GMT Subject: RFR: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote: > Trivial comment only change in a test. Please review! > > Thanks! Marked as reviewed by gdams (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/20051#pullrequestreview-2160518890 From stuefe at openjdk.org Fri Jul 5 11:32:19 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 5 Jul 2024 11:32:19 GMT Subject: RFR: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file In-Reply-To: References: Message-ID: <25PCKZP6wuOWfe47W6WovJq1ibOCCqH57rc1TPVQIdM=.91df2ea2-0c96-4f40-a78c-705f5dfb8adb@github.com> On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote: > Trivial comment only change in a test. Please review! > > Thanks! Good and trivial Marked as reviewed by stuefe (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20051#pullrequestreview-2160533824 PR Review: https://git.openjdk.org/jdk/pull/20051#pullrequestreview-2160534056 From sgehwolf at openjdk.org Fri Jul 5 12:09:18 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 12:09:18 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v3] In-Reply-To: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> References: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> Message-ID: On Fri, 5 Jul 2024 10:56:37 GMT, Thomas Stuefe wrote: >> The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > problemlist Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20034#pullrequestreview-2160590870 From sgehwolf at openjdk.org Fri Jul 5 12:13:17 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 12:13:17 GMT Subject: RFR: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote: > Trivial comment only change in a test. Please review! > > Thanks! Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20051#issuecomment-2210765310 From sgehwolf at openjdk.org Fri Jul 5 13:47:21 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 5 Jul 2024 13:47:21 GMT Subject: Integrated: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote: > Trivial comment only change in a test. Please review! > > Thanks! This pull request has now been integrated. Changeset: ff49f677 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/ff49f677ee5017019c90823bc412ceb90068ffbd Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file Reviewed-by: gdams, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/20051 From kevinw at openjdk.org Fri Jul 5 14:27:22 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 5 Jul 2024 14:27:22 GMT Subject: RFR: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) Message-ID: The test test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java should be removed. This test was added when 6984520 was fixed in 6u25. It has been problemlisted since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it just wanted something "RMI" to connect with). Looking at the change it tested, the code is no longer the same, and is no longer at risk of this NPE. The original NPE fix was to check that jxmServerviceURL was not null before calling methods on it, but the current RMIConnector.java does not make those same calls. It is best to remove the test and its problemlist entry. ------------- Commit messages: - 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) Changes: https://git.openjdk.org/jdk/pull/20054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267887 Stats: 79 lines in 2 files changed: 0 ins; 79 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20054/head:pull/20054 PR: https://git.openjdk.org/jdk/pull/20054 From sspitsyn at openjdk.org Fri Jul 5 20:49:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 5 Jul 2024 20:49:33 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. Okay to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20025#pullrequestreview-2161247996 From duke at openjdk.org Mon Jul 8 05:30:40 2024 From: duke at openjdk.org (duke) Date: Mon, 8 Jul 2024 05:30:40 GMT Subject: Withdrawn: 8330171: Lazy W^X switch implementation In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com> References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com> Message-ID: On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote: > An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed. Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). > > Additional testing: > - [x] MacOS AArch64 server fastdebug *gtets* > - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4* > - [ ] Benchmarking > > @apangin and @parttimenerd could you please check the patch on your scenarios?? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18762 From dholmes at openjdk.org Mon Jul 8 06:49:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Jul 2024 06:49:34 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v3] In-Reply-To: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> References: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> Message-ID: On Fri, 5 Jul 2024 10:56:37 GMT, Thomas Stuefe wrote: >> The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > problemlist Seems okay. Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20034#pullrequestreview-2162410407 From dholmes at openjdk.org Mon Jul 8 06:56:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Jul 2024 06:56:32 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 09:23:21 GMT, KIRIYAMA Takuya wrote: > This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. > > When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. > https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 > > > if (getMethod().getName().asString().equals("wait") && > getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { > > > However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. > > I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". > I confirmed that the lock information is correctly printed with this fix. > I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. > > Would anyone review this change, please? Good catch on the underlying issue. I think the test needs an adjustment though. Thanks test/hotspot/jtreg/serviceability/sa/LingeredAppWithLock.java line 54: > 52: Thread objectLock = new Thread(() -> lockMethod(classLock1)); > 53: Thread primitiveLock = new Thread(() -> lockMethod(int.class)); > 54: Thread objectWait = new Thread(() -> waitMethod(new Object())); Use of `new Object()` could be problematic here as the JIT can recognise that this is a non-escaping object and elide the synchronization. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20049#pullrequestreview-2162420583 PR Review Comment: https://git.openjdk.org/jdk/pull/20049#discussion_r1668084668 From stuefe at openjdk.org Mon Jul 8 08:09:37 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Jul 2024 08:09:37 GMT Subject: Integrated: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 12:57:09 GMT, Thomas Stuefe wrote: > The new System.map facility fails its tests when the JVM is using ZGC. The facility is working fine, but the test checks for the java heap to appear as committed non-shared memory segment, but on ZGC we reserve the memory as shared memory. This pull request has now been integrated. Changeset: 3cce31ad Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/3cce31ad8877ec62429981871bcb0067770f9ccb Stats: 9 lines in 3 files changed: 2 ins; 6 del; 1 mod 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 Reviewed-by: sgehwolf, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/20034 From stuefe at openjdk.org Mon Jul 8 08:09:36 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Jul 2024 08:09:36 GMT Subject: RFR: 8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475 [v3] In-Reply-To: References: <0uSdlOhZGqRvep4l_bLTqxaT3gTDe0ULZ8E4tgpIB0k=.187e195e-f030-4224-a260-61f8950407c4@github.com> Message-ID: <-H3ARdj0kiDhTJoOP6478-2-T0Fx7NVLnRaIRcJcRNQ=.2ddce751-6422-463c-ba49-005c66b7bdca@github.com> On Mon, 8 Jul 2024 06:46:34 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> problemlist > > Seems okay. > > Thanks for fixing. Thanks @dholmes-ora and @jerboaa ------------- PR Comment: https://git.openjdk.org/jdk/pull/20034#issuecomment-2213308314 From aboldtch at openjdk.org Mon Jul 8 08:25:02 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 08:25:02 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping Message-ID: When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. # Cleanups Cleaned up displaced header usage for: * BasicLock * Contains some Zero changes * Renames one exported JVMCI field * ObjectMonitor * Updates comments and tests consistencies # Refactoring `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ # LightweightSynchronizer Working on adapting and incorporating the following section as a comment in the source code ## Fast Locking CAS on locking bits in markWord. 0b00 (Fast Locked) <--> 0b01 (Unlocked) When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inflated locking is performed. ### Fast Lock Spinning (UseObjectMonitorTable) When a thread fails fast locking when a monitor is not yet inflated, it will spin on the markWord using a exponential backoff scheme. The thread will attempt the fast lock CAS and then SpinWait() for some time, doubling with every failed attempt, up to a maximum number of attempts. There is a diagnostic VM option LightweightFastLockingSpins which can be used to tune this value. The behavior of SpinWait() can be hardware dependent. A future improvement may be to adapt this spinning limit to observed behavior. Which would automatically adapt to the different hardware behavior of SpinWait(). ## Inflated Locking Inflated locking means that a ObjectMonitor is associated with the object and is used for locking instead of the locking bits in the markWord. ## Inflated Locking without table (!UseObjectMonitorTable) An inflating thread will create a ObjectMonitor and CAS the ObjectMonitor* into the markWord along with the 0b10 (Inflated) lock bits. If the transition of the lock bits is from 0b00 (Fast Locked) the ObjectMonitor must be published with an anonymous owner (setting _owner to ANONYMOUS_OWNER). If the transition of the lock bits is from 0b00 (Unlocked) the ObjectMonitor is published with no owner. When encountering an ObjectMonitor with an anonymous owner the thread checks its lock stack to see if it is the owner, in which case it removes the object from its lock stack and sets itself as the owner of the ObjectMonitor along with fixing the recursion level to correspond to the number of removed lock stack entires. ## Inflated Locking with table (UseObjectMonitorTable) Because publishing the ObjectMonitor* and signaling that a object's monitor is inflated is not atomic, more care must be taken (in the presence of deflation) so that all threads agree on which ObjectMonitor* to use. When encountering an ObjectMonitor with an anonymous owner the thread checks its lock stack to see if it is the owner, in which case it removes the object from its lock stack and sets itself as the owner of the ObjectMonitor along with fixing the recursion level to correspond to the number of removed lock stack entires. All complications arise from deflation, or the process of disassociating an ObjectMonitor from its Java Object. So first the mechanism used for deflation is explained. Followed by retrieval and creation of ObjectMonitors. ### Deflation An ObjectMonitor can only be deflated if it has no owner, its queues are empty and no thread is in a scope where it has incremented and checked the contentions reference counter. The interactions between deflation and wait is handled by having the owner and wait queue entry overlap to blocks out deflation; the wait queue entry is protected by a waiters reference counter which is only modified by the waiters while holding the monitor, incremented before exiting the monitor and decremented after reentering the monitor. For enter and exit where the deflator may observe empty queues and no owner a two step mechanism is used to synchronize deflation with concurrently locking threads; deflation is synchronized using the contentions reference counter. In the text below we refer to "holding the contentions reference counter". This means that a thread has incremented the contentions reference counter and verified that it is not negative. ```c++ if (Atomic::fetch_and_add(&monitor->_contentions, 1) >= 0) { // holding the contentions reference counter } Atomic::decrement(&monitor->_contentions); ``` #### Deflation protocol The first step for the deflator is to try and CAS the owner from no owner to a special marker (DEFLATER_MARKER). If this is successful it blocks any entering thread from successfully installing themselves as the owner and causes compiled code to take a slow path and call into the runtime. The second step for the deflator is to check waiters reference counter and if it is 0 try CAS the contentions reference counter from 0 to a large negative value (INT_MIN). If this succeeds the monitor is deflated. The deflator does not have to check the entry queues because every thread on the entry queues must have either hold the contentions reference counter, or incremented the waiters reference counter, in the case they were moved from the wait queue to the entry queues by a notify. The deflator check the waiters reference counter, with the memory ordering of Waiter: { increment waiters reference counter; release owner }, Deflator: { acquire owner; check waiters reference counter }. All threads on the entry queues or wait queue invariantly holds the contentions reference counter or the waiters reference counter. #### Deflation cleanup If deflation succeeds, locking bits are then transitioned back to 0b01 (Unlocked). With UseObjectMonitorTable it is required that this is done by the deflator, or it could lead to ABA problems in the locking bits. Without the table the whole ObjectMonitor* is part of the markWord transition, with its pointer being phased out of the system with a handshake, making every value distinguishable and avoiding ABA issues. For UseObjectMonitorTable the deflated monitor is also removed from the table. This is done after transitioning the markWord to allow concurrently entering threads to fast lock on the object while the monitor is being removed from the hash table. If deflation fails after the marker (DEFLATER_MARKER) has been CASed into the owner field the owner must be restored. From the deflation threads point of view it is as simple as CASing from the marker to no owner. However to not have all threads depend on the deflation thread making progress here we allow any thread to CAS from the marker if that thread has both incremented and checked the contentions counter. This thread has now effectively canceled the deflation, but it is important that the deflator observes this fact, we do this by forgetting to decrement the contentions counter. The effect is that the contentions CAS will fail, which will force the deflator to try and restore the owner, but this will also fail because it got canceled. So the deflator decrements the contentions counter instead on behalf of the canceling thread to balance the reference counting. (Currently this is implemented by doing a +1 +1 -1 reference count on the locking thread, but a simple only +1 would s uffice). ### Retrieve ObjectMonitor #### HashTable Maintains a mapping between Java Objects and ObjectMonitors. Lookups are done via the objects identity_hash. If the hash table contains an ObjectMonitor for a specific object then that ObjectMonitor is used for locking unless it is being deflated. Only deflation removes (not dead) entries inside the HashTable. #### ThreadLocal Cache (UseObjectMonitorTable) The most recently locked ObjectMonitors by a thread are cached in that thread's local storage. These are used to elide hash table lookups. These caches uses raw oops to make cache lookups trivial. However this requires special handling of the cache at safepoints. The caches are cleared when a safepoint is triggered (instead of letting the gc visit them), this to avoid keeping cache entries as gc roots. These cache entires may become deflated, but locking on such a monitor still participates in the normal deflation protocol. Because these entries are cleared during a safepoint, the handshake performed by monitor deflation to phase out ObjectMonitor* from the system will also phase these out. #### StackLocal Cache Each monitorenter has a corresponding BasicLock entry on the stack. Each successful inflated monitorenter saves the ObjectMonitor* inside this BasicLock entry and retrieves it when performing the corresponding monitorexit. This means it is important that the BasicLock entry is always initialized to a known state (nullptr is used). The RAII object class CacheSetter is used to ensure that the BasicLock gets initialized before leaving the runtime code, and that both caches gets updated correctly. (Only once, with the same locked ObjectMonitor). The cache entries are set when a monitor is entered and never used again after a that monitored has been exited. So there are no interactions with deflation here. Similarly these caches does not track the associated oop, but rely on the fact that the same BasicLock data created for a monitorenter is used when executing the corresponding monitorexit. ### Creating ObjectMonitor If retrieval of the ObjectMonitor fails, because there is no ObjectMonitor, either because this is the first time inflating or the ObjectMonitor has been deflated a new ObjectMonitor must be created and associated with the object. The inflating thread will then attempt to insert a newly created ObjectMonitor in the hash table. The important invariant is that any ObjectMonitor inserted must have an anonymous owner (setting _owner to ANONYMOUS_OWNER). This solves the issue of not being able to atomically inserting the ObjectMonitor in the hash table, and transitioning the markWord to 0b10 (Inflated). We instead have all inflating threads insert an identical anonymously owned ObjectMonitor in the table and then decide ownership based on how the markWord is transitioned to 0b10 (Inflated). Note: Only one ObjectMonitor can be inserted. This also has the effect of blocking deflation on a newly inserted ObjectMonitor, until the contentions reference counter can be incremented. The contentions reference counter is held while transitioning the markWord to block out deflation. * If a thread observes 0b10 (Inflated) * If the current thread is the thread that fast locked, take ownership. Update ObjectMonitor _recursions based on fast locked recursions. Call ObjectMonitor::enter(current); * Otherwise Some other thread is the owner, and will claim ownership. Call ObjectMonitor::enter(current); * If a thread succeeds with the CAS to 0b10 (Inflated) * From 0b00 (Fast Locked) * If the current thread is the thread that fast locked, take ownership. Update ObjectMonitor _recursions based on fast locked recursions. Call ObjectMonitor::enter(current); * Otherwise Some other thread is the owner, and will claim ownership. Call ObjectMonitor::enter(current); * From 0b01 (Unlocked) * Claim ownership, no ObjectMonitor::enter is required. * If a thread fails the CAS reload markWord and retry ### Un-contended Inflated Locking CAS on _owner field in ObjectMonitor. JavaThread* (Locked By Thread) <--> nullptr (Unlocked) ### Contended Inflated Locking Blocks out deflation. Spin CAS on _owner field in ObjectMonitor. JavaThread* (Locked By Thread) <--> nullptr (Unlocked) Details in ObjectMonitor.hpp ### HashTable Resizing and Cleanup Resizing is currently handled with the similar logic to what the string and symbol table uses. And is delegated to the ServiceThread. The goal is to eventually this to deflation thread, to allow for better interactions with the deflation cycles, making it possible to also shrink the table. But this will be done incrementally as a separate enhancement. The ServiceThread is currently used to deal with the fact that we currently allow the deflation thread to be turned off via JVM options. Cleanup is mostly handled by the the deflator which actively removes deflated monitors, which includes monitors for dead objects. However we allow any thread to remove dead objects' ObjectMonitor* associations. But actual memory reclamation of the ObjectMonitor is always handled by the deflator. The table is currently initialized before `init_globals`, as such the max size of the table which is based on `MaxHeapSize` may be incorrect because it is not yet finalized. ------------- Commit messages: - 8315884: New Object to ObjectMonitor mapping Changes: https://git.openjdk.org/jdk/pull/20067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315884 Stats: 3613 lines in 70 files changed: 2700 ins; 313 del; 600 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From Alan.Bateman at oracle.com Mon Jul 8 09:18:34 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Jul 2024 10:18:34 +0100 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: On 03/07/2024 11:26, Thiago Henrique Hupner wrote: > Dear JDK developers, > > I'd like to propose adding an option that allows the JVM to ignore a > non-existent -javaagent instead of aborting. > > Currently, if a -javaagent is specified but the agent jar file doesn't > exist, the JVM aborts with an error. This can cause issues in > environments where the same JVM arguments are used across different > systems, but not all systems have the agent installed. In general you can't assume that the same VM options or arguments to the java launcher can be used across different systems, different JDK releases, or in this case specifying a tool agent that may not be installed or may be installed in a different location. For this case it may be better to re-visit the launch script for the application so that it conditionally adds the -javaagent option when the tool agent is needed. -Alan From duke at openjdk.org Mon Jul 8 09:42:31 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 09:42:31 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas wrote: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Is this change expected to require JVMCI and/or Graal JIT changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213534062 From aboldtch at openjdk.org Mon Jul 8 10:14:32 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 10:14:32 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote: > Is this change expected to require JVMCI and/or Graal JIT changes? Support for `UseObjectMonitorTable` would require changes to Graal JIT. (`UseObjectMonitorTable` is off by default). Minimal support would be to call into the VM for inflated monitors. (Similarly to what this patch does for C2 for none x86 / aarch64 platforms). For starting the VM normally without `UseObjectMonitorTable` no semantic change is required. All locking modes and VM invariants w.r.t. locking are the same. As mentioned this patch contains a refactoring which renames one exported `JVMCI` symbol which I suspect should only be used by Graal JIT for `LM_LEGACY`. As such the Graal JIT needs to be updated to use this new symbol name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213602121 From duke at openjdk.org Mon Jul 8 11:01:32 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 11:01:32 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: References: Message-ID: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas wrote: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... OK. Will there be a CSR or JEP for this? When do you approximately expect this to land in main line? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213689308 From mbaesken at openjdk.org Mon Jul 8 11:10:42 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jul 2024 11:10:42 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 Message-ID: Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : serviceability/dcmd/vm/SystemDumpMapTest.java Missing patterns in dump: 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] test SystemDumpMapTest.jmx(): failure java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) at SystemDumpMapTest.run(SystemDumpMapTest.java:106) at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) .... Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. So better avoid the check because it is based on false assumptions. ------------- Commit messages: - JDK-8335710 Changes: https://git.openjdk.org/jdk/pull/20072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335710 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20072/head:pull/20072 PR: https://git.openjdk.org/jdk/pull/20072 From aboldtch at openjdk.org Mon Jul 8 11:55:33 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 11:55:33 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping In-Reply-To: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> References: <4BqqOjbfNOV6NjtPe-hIf-98N8kT6ce_FBCuQ-vqBBY=.6e02875c-908f-43f0-8d66-ba4f5b01d488@github.com> Message-ID: On Mon, 8 Jul 2024 10:58:29 GMT, Thomas Wuerthinger wrote: > OK. Will there be a CSR or JEP for this? There is no plan for this, nor should it be required. It?s an internal implementation. > When do you approximately expect this to land in main line? ASAP. Compatibility for the field name is being worked on in Graal JIT. The plan is not to integrate this prior to this work being completed. We should probably add a more graceful transition. Such that `UseObjectMonitorTable` is turned off ergonomically even if the user specified it when running with JVMCI enabled. The main goal here is to get something in main line which does not affect the default behaviour of the VM. But allows for supporting future features such as Lilliput, along with enabling incremental improvement to `UseObjectMonitorTable` via support for more platforms and compiler backends, performance improvements, etc to be done towards the JDK project. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213806034 From aboldtch at openjdk.org Mon Jul 8 12:13:07 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 12:13:07 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: More graceful JVMCI VM option interaction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/4d835b94..28143503 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From duke at openjdk.org Mon Jul 8 12:16:51 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 8 Jul 2024 12:16:51 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: References: Message-ID: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> > This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. > > When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. > https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 > > > if (getMethod().getName().asString().equals("wait") && > getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { > > > However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. > > I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". > I confirmed that the lock information is correctly printed with this fix. > I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. > > Would anyone review this change, please? KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8335743: jhsdb jstack cannot print some information on the waiting thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20049/files - new: https://git.openjdk.org/jdk/pull/20049/files/1daff6fa..8ebc2b4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20049/head:pull/20049 PR: https://git.openjdk.org/jdk/pull/20049 From duke at openjdk.org Mon Jul 8 12:18:34 2024 From: duke at openjdk.org (Thomas Wuerthinger) Date: Mon, 8 Jul 2024 12:18:34 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: <15fwghNOC4j6Hctnqn7sVKsRFbHGs7mwcgpadcok1qo=.63b2a07a-2fe0-4557-843d-f6b131e37a09@github.com> On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > More graceful JVMCI VM option interaction OK, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2213887069 From duke at openjdk.org Mon Jul 8 12:20:34 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 8 Jul 2024 12:20:34 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 06:52:34 GMT, David Holmes wrote: >> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: >> >> 8335743: jhsdb jstack cannot print some information on the waiting thread > > test/hotspot/jtreg/serviceability/sa/LingeredAppWithLock.java line 54: > >> 52: Thread objectLock = new Thread(() -> lockMethod(classLock1)); >> 53: Thread primitiveLock = new Thread(() -> lockMethod(int.class)); >> 54: Thread objectWait = new Thread(() -> waitMethod(new Object())); > > Use of `new Object()` could be problematic here as the JIT can recognise that this is a non-escaping object and elide the synchronization. Hello, @dholmes-ora, thank you for your advice. As you pointed out, there was a problem. I fixed it, so please check it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20049#discussion_r1668521793 From sgehwolf at openjdk.org Mon Jul 8 14:23:43 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 14:23:43 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Message-ID: Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. ------------- Commit messages: - 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Changes: https://git.openjdk.org/jdk/pull/20076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335882 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20076/head:pull/20076 PR: https://git.openjdk.org/jdk/pull/20076 From sgehwolf at openjdk.org Mon Jul 8 14:26:32 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 14:26:32 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. @MBaesken Since you've noticed the failing test in your CI could you please verify the issue is gone with this? I don't have an Alpine Linux setup to easily test this exclusion. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214223234 From stuefe at openjdk.org Mon Jul 8 14:32:41 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 8 Jul 2024 14:32:41 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <3sI4EIbYUqfFhVL1b0SdHJ04q3_lYo7eVijw9R3CqrQ=.7938875e-ef0c-4de4-ac93-54c223da2552@github.com> On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Seems fine. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20076#pullrequestreview-2163517084 From mbaesken at openjdk.org Mon Jul 8 14:32:42 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 Jul 2024 14:32:42 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:12 GMT, Severin Gehwolf wrote: > @MBaesken Since you've noticed the failing test in your CI could you please verify the issue is gone with this? I don't have an Alpine Linux setup to easily test this exclusion. Thanks! Hi Severin, sure ! I put it into our build/test setup . ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214228730 From yzheng at openjdk.org Mon Jul 8 14:55:36 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 8 Jul 2024 14:55:36 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > More graceful JVMCI VM option interaction Could you please revert 2814350 and export the following symbols to JVMCI? diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp index faf2cb24616..7be31aa0f5f 100644 --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp @@ -241,6 +241,7 @@ nonstatic_field(JavaThread, _stack_overflow_state._reserved_stack_activation, address) \ nonstatic_field(JavaThread, _held_monitor_count, intx) \ nonstatic_field(JavaThread, _lock_stack, LockStack) \ + nonstatic_field(JavaThread, _om_cache, OMCache) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_in_VTMS_transition, bool)) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_in_tmp_VTMS_transition, bool)) \ JVMTI_ONLY(nonstatic_field(JavaThread, _is_disable_suspend, bool)) \ @@ -531,6 +532,8 @@ \ declare_constant_with_value("CardTable::dirty_card", CardTable::dirty_card_val()) \ declare_constant_with_value("LockStack::_end_offset", LockStack::end_offset()) \ + declare_constant_with_value("OMCache::oop_to_oop_difference", OMCache::oop_to_oop_difference()) \ + declare_constant_with_value("OMCache::oop_to_monitor_difference", OMCache::oop_to_monitor_difference()) \ \ declare_constant(CodeInstaller::VERIFIED_ENTRY) \ declare_constant(CodeInstaller::UNVERIFIED_ENTRY) \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2214322632 From sgehwolf at openjdk.org Mon Jul 8 15:05:33 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Jul 2024 15:05:33 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <64d4ndFMHM7jY5tvHNMHJgJebojmfmKKa6YlW6MEPew=.2ff2ab15-3647-4708-b1d1-8c7267684956@github.com> On Mon, 8 Jul 2024 14:26:29 GMT, Matthias Baesken wrote: > Hi Severin, sure ! I put it into our build/test setup . Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214368557 From aboldtch at openjdk.org Mon Jul 8 16:21:16 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Jul 2024 16:21:16 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: Message-ID: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Add JVMCI symbol exports - Revert "More graceful JVMCI VM option interaction" This reverts commit 2814350370cf142e130fe1d38610c646039f976d. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/28143503..173b75b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=01-02 Stats: 8 lines in 2 files changed: 3 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From ayang at openjdk.org Mon Jul 8 16:24:08 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Jul 2024 16:24:08 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC Message-ID: Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. ------------- Commit messages: - pgc-vm-operation Changes: https://git.openjdk.org/jdk/pull/20077/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335902 Stats: 352 lines in 14 files changed: 96 ins; 169 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/20077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20077/head:pull/20077 PR: https://git.openjdk.org/jdk/pull/20077 From ayang at openjdk.org Mon Jul 8 16:31:43 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Jul 2024 16:31:43 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v2] In-Reply-To: References: Message-ID: > Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. > > The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. > > Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: pgc-vm-operation ------------- Changes: https://git.openjdk.org/jdk/pull/20077/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=01 Stats: 352 lines in 14 files changed: 96 ins; 169 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/20077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20077/head:pull/20077 PR: https://git.openjdk.org/jdk/pull/20077 From cjplummer at openjdk.org Mon Jul 8 17:57:34 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 8 Jul 2024 17:57:34 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> References: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> Message-ID: <78f7sQV7Robv6vnTmgM_ax_vPqJEiEpK_FcZ42Q75IA=.b4ae98b4-8aab-426e-a179-8629837b149c@github.com> On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. >> https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 >> >> >> if (getMethod().getName().asString().equals("wait") && >> getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { >> >> >> However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. >> >> I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". >> I confirmed that the lock information is correctly printed with this fix. >> I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. >> >> Would anyone review this change, please? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8335743: jhsdb jstack cannot print some information on the waiting thread Looks good. Thank you for adding the test. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20049#pullrequestreview-2164004455 From cjplummer at openjdk.org Mon Jul 8 18:12:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 8 Jul 2024 18:12:33 GMT Subject: [jdk23] RFR: 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range In-Reply-To: <7JorVYHv2FWSlD4ZQ3cEK_jQfKJweCJkH5jaNG_nsFw=.8e697bb4-260f-4ac6-bb86-6f6fb6e03f60@github.com> References: <7JorVYHv2FWSlD4ZQ3cEK_jQfKJweCJkH5jaNG_nsFw=.8e697bb4-260f-4ac6-bb86-6f6fb6e03f60@github.com> Message-ID: On Wed, 3 Jul 2024 08:24:43 GMT, Kevin Walls wrote: > Clean backport to jdk23 of a simple test update, to try and avoid spurious failures. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19999#pullrequestreview-2164031769 From cjplummer at openjdk.org Mon Jul 8 18:16:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 8 Jul 2024 18:16:33 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: <8fzuIYuEccEuEH1Qm4yeX4-qKLkN770Pp3HhSvyFxhA=.b2fb581b-9a31-476c-82b1-d62bb776ddf6@github.com> On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239: > 237: " > ThreadUserTime = " + utime2); > 238: } > 239: */ Shouldn't this be uncommented and this bit of testing restored? It seems the only reason it was commented out is because of Solaris, which we don't need to worry about anymore. Probably best to leave this to a separate PR if you are going to restore it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20025#discussion_r1669075901 From kevinw at openjdk.org Mon Jul 8 21:12:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Jul 2024 21:12:33 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: <8fzuIYuEccEuEH1Qm4yeX4-qKLkN770Pp3HhSvyFxhA=.b2fb581b-9a31-476c-82b1-d62bb776ddf6@github.com> References: <8fzuIYuEccEuEH1Qm4yeX4-qKLkN770Pp3HhSvyFxhA=.b2fb581b-9a31-476c-82b1-d62bb776ddf6@github.com> Message-ID: On Mon, 8 Jul 2024 18:13:33 GMT, Chris Plummer wrote: >> There are two similarly names tests. >> Recently: >> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range >> ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. >> >> Also removing an old comment about a Solaris issue. > > test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239: > >> 237: " > ThreadUserTime = " + utime2); >> 238: } >> 239: */ > > Shouldn't this be uncommented and this bit of testing restored? It seems the only reason it was commented out is because of Solaris, which we don't need to worry about anymore. Probably best to leave this to a separate PR if you are going to restore it. Would have been happy to test it and bring it back, have looked into it more: back in jdk5u we have the same commented out code, we have never run this in general testing. I think it's redundant, the two calls are equivalent. long utime1 = mbean.getCurrentThreadUserTime(); "This is a convenient method for local management use and is equivalent to calling: getThreadUserTime(Thread.currentThread().getId());" ..which is the other time we would be comparing it with: long utime2 = mbean.getThreadUserTime(getId()); (in this class that extends Thread). I think we can presume some os-specific quirk that does not affect us today! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20025#discussion_r1669325187 From cjplummer at openjdk.org Tue Jul 9 04:49:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 9 Jul 2024 04:49:04 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent Message-ID: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. Testing in progress: tier1 and tier5 svc testing ------------- Commit messages: - Fix issue with main thread being suspended Changes: https://git.openjdk.org/jdk/pull/20088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8072701 Stats: 10 lines in 1 file changed: 7 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20088/head:pull/20088 PR: https://git.openjdk.org/jdk/pull/20088 From dholmes at openjdk.org Tue Jul 9 08:24:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Jul 2024 08:24:34 GMT Subject: RFR: 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException [v2] In-Reply-To: <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com> References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com> <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com> Message-ID: On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls wrote: >> Disable running this test with -Xcomp. >> >> The NPE seen in this test is due to a timeout establishing the connection. ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection. >> >> -Xcomp causes this slowdown and the failure is reproducible. There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment Okay ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19930#pullrequestreview-2165445432 From kevinw at openjdk.org Tue Jul 9 08:24:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 08:24:34 GMT Subject: RFR: 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException [v2] In-Reply-To: <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com> References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com> <9FY2VW_Ny11qLW-J2zNcCVxJegPctIFXsWd7Q4VACQ4=.49014b43-0ff1-4bf4-a505-5633934c86b0@github.com> Message-ID: On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls wrote: >> Disable running this test with -Xcomp. >> >> The NPE seen in this test is due to a timeout establishing the connection. ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection. >> >> -Xcomp causes this slowdown and the failure is reproducible. There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19930#issuecomment-2216919357 From kevinw at openjdk.org Tue Jul 9 08:27:40 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 08:27:40 GMT Subject: Integrated: 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException In-Reply-To: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com> References: <-_HSPKzz3cGo1YpDj_lpT_hhg59LbEfXSzJ6tnltcBA=.03bfeffb-260f-4ba2-8a2a-87d03b884995@github.com> Message-ID: On Thu, 27 Jun 2024 15:53:09 GMT, Kevin Walls wrote: > Disable running this test with -Xcomp. > > The NPE seen in this test is due to a timeout establishing the connection. ServerCommunicatorAdmin hits its timeout, during an addNotificationListener call on a new connection. > > -Xcomp causes this slowdown and the failure is reproducible. There is no need to test this test with -Xcomp, we should exclude it as we do for various other tests. This pull request has now been integrated. Changeset: 2a296475 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/2a2964759c73b3b9ab6afaad109383c89952977b Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/19930 From jpai at openjdk.org Tue Jul 9 08:46:57 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Jul 2024 08:46:57 GMT Subject: RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Message-ID: Can I please get a review of this change which removes an incorrect entry from `ProblemList-Virtual.txt`? As noted in https://bugs.openjdk.org/browse/JDK-8335966 this entry is a left over which went unnoticed when we did the changes in https://bugs.openjdk.org/browse/JDK-8333130. The refactored test `NativeMethodPrefixApp` has been functioning without the errors for which `NativeMethodPrefixAgent` was previously problem listed. So I haven't replaced that problem list entry and instead have just removed it. `NativeMethodPrefixApp` is known to run into an intermittent timeout with virtual threads and that's tracked in https://bugs.openjdk.org/browse/JDK-8334167 and I think it's not problem listing worthy given the relatively low frequency of such timeouts. Furthermore, in the coming days, I plan to propose a change to this `NativeMethodPrefixApp` test which should fix the timeout failures. To verify that this removal doesn't cause any unexpected issues, I've triggered a CI run of the relevant tier. ------------- Commit messages: - 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Changes: https://git.openjdk.org/jdk/pull/20094/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20094&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335966 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20094.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20094/head:pull/20094 PR: https://git.openjdk.org/jdk/pull/20094 From mbaesken at openjdk.org Tue Jul 9 09:19:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 9 Jul 2024 09:19:32 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Marked as reviewed by mbaesken (Reviewer). The issue is gone in our tests, with your patch added. ------------- PR Review: https://git.openjdk.org/jdk/pull/20076#pullrequestreview-2165630718 PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2217120494 From kevinw at openjdk.org Tue Jul 9 09:36:32 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 09:36:32 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Tue, 9 Jul 2024 04:43:59 GMT, Chris Plummer wrote: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing Read through and counted suspend/resumes on my fingers, seems good. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2165680314 From kevinw at openjdk.org Tue Jul 9 09:40:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 09:40:34 GMT Subject: RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 08:39:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an incorrect entry from `ProblemList-Virtual.txt`? > > As noted in https://bugs.openjdk.org/browse/JDK-8335966 this entry is a left over which went unnoticed when we did the changes in https://bugs.openjdk.org/browse/JDK-8333130. > > The refactored test `NativeMethodPrefixApp` has been functioning without the errors for which `NativeMethodPrefixAgent` was previously problem listed. So I haven't replaced that problem list entry and instead have just removed it. > > `NativeMethodPrefixApp` is known to run into an intermittent timeout with virtual threads and that's tracked in https://bugs.openjdk.org/browse/JDK-8334167 and I think it's not problem listing worthy given the relatively low frequency of such timeouts. Furthermore, in the coming days, I plan to propose a change to this `NativeMethodPrefixApp` test which should fix the timeout failures. > > To verify that this removal doesn't cause any unexpected issues, I've triggered a CI run of the relevant tier. looks good ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20094#pullrequestreview-2165691687 From sgehwolf at openjdk.org Tue Jul 9 10:24:39 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 9 Jul 2024 10:24:39 GMT Subject: RFR: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. Thanks for the reviews! The docs build failure in GHA is infra related: Run # If runner architecture is x64 set JAVA_HOME_17_X64 otherwise set to JAVA_HOME_17_arm64 [build.sh][INFO] CYGWIN_OR_MSYS=0 [build.sh][INFO] JAVA_HOME: /usr/lib/jvm/temurin-17-jdk-amd64 [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk/jdk/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip Error: sh][ERROR] wget exited with exit code 4 Error: Process completed with exit code 1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2217257118 From sgehwolf at openjdk.org Tue Jul 9 10:24:40 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 9 Jul 2024 10:24:40 GMT Subject: Integrated: 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux In-Reply-To: References: Message-ID: <804gKEmpNT4ym9osB0uQmqan-qUveSmOVRX_OXBODNU=.4ed36f94-0673-4667-9745-1b023f7b0469@github.com> On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote: > Please review this simple test fix to exclude the test from being run on an Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups set up by default the way other distros do. More info on the bug. I propose to not run the test on musl systems. This pull request has now been integrated. Changeset: f3ff4f74 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/f3ff4f7427c3c3f5cb2a115a61462bb9d28de1cd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux Reviewed-by: stuefe, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/20076 From lucy at openjdk.org Tue Jul 9 11:13:31 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 9 Jul 2024 11:13:31 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. Looks good. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20072#pullrequestreview-2166005745 From alanb at openjdk.org Tue Jul 9 12:19:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Jul 2024 12:19:32 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Fri, 5 Jul 2024 07:28:13 GMT, Volker Simonis wrote: > @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? (Catching up as I was away for a few days). I agree it would be useful to have an API note on this topic. There were several reports of deadlocks, ClassCircularityError, and other hard to diagnose issues when support for instrumentation was originally introduced in JDK 5. I think agent maintainers learned to exclude many of the core classes in java.base but that is always a moving target and there have been a few more sightings/reports recently (maybe due to newer features doing more in Java rather than in the VM). I agree that the ClassFileTransformer class description is the best place for this. My initial reaction was to wonder about the j.l.instrument package description but it is more focused on starting agents and the JAR file attributes so I think your proposed location is best.. As regards the text then it might be better to start with a sentence to say that the "transform" method may be called from critical points in JDK core classes or called to transform JDK core classes. You've got some of this in second sentence but I think better to lead with it before revealing one of the several possible things that can happen. I think part of the lead in needs to say "great care must be taken" or something like that to get across the point that the ClassFileTransformer implementor has the potential to cause many possible issues. For the same class and linkage error then probably best to not use the phrase "transitively requires" as it's too close "requires transitive" used in module declarations. Note that the `@jvms` tag can be used to reference the JVMS section. You'll see a few examples in other classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2217495130 From stuefe at openjdk.org Tue Jul 9 12:28:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 9 Jul 2024 12:28:32 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. Wait, didn't I fix this already? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2217528047 From stuefe at openjdk.org Tue Jul 9 12:34:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 9 Jul 2024 12:34:32 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. I dislike having no test that checks that standard OS-side segments are shown. Does Alpine have a [heap] segment at least? Could scan for that. ------------- PR Review: https://git.openjdk.org/jdk/pull/20072#pullrequestreview-2166183789 From stuefe at openjdk.org Tue Jul 9 12:34:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 9 Jul 2024 12:34:32 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 12:26:01 GMT, Thomas Stuefe wrote: > Wait, didn't I fix this already? Weird, I could have sworn I fixed that. Ah well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2217557748 From stuefe at openjdk.org Tue Jul 9 12:55:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 9 Jul 2024 12:55:32 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 12:32:06 GMT, Thomas Stuefe wrote: > I dislike having no test that checks that standard OS-side segments are shown. > > Does Alpine have a [heap] segment at least? Could scan for that. Checked and Alpine processes have a `[heap]` segment. Could you try that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2217648113 From coleenp at openjdk.org Tue Jul 9 13:00:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Jul 2024 13:00:33 GMT Subject: RFR: 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests In-Reply-To: References: Message-ID: <7jUH7bD3fkg3Yt9CS8ZDKsBg9Mza2fccyQefHR9AdB4=.bf4af4b1-3799-401b-af68-3ac8f302bab1@github.com> On Thu, 4 Jul 2024 12:15:09 GMT, Kim Barrett wrote: > Please review this change to some jvmti tests, which were calling fflush with > an argument of 0. Most of these are in C++ code, where we change them to use > nullptr as the argument. A couple are in C, where we change them to use NULL. > This removes a bunch of -Wzero-as-null-pointer-constant when building with > that enabled. > > Testing: mach5 tier1 Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20032#pullrequestreview-2166246812 From kbarrett at openjdk.org Tue Jul 9 13:14:36 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Jul 2024 13:14:36 GMT Subject: RFR: 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 07:51:08 GMT, Julian Waters wrote: >> Please review this change to some jvmti tests, which were calling fflush with >> an argument of 0. Most of these are in C++ code, where we change them to use >> nullptr as the argument. A couple are in C, where we change them to use NULL. >> This removes a bunch of -Wzero-as-null-pointer-constant when building with >> that enabled. >> >> Testing: mach5 tier1 > > Marked as reviewed by jwaters (Committer). Thanks for reviews @TheShermanTanker and @coleenp ------------- PR Comment: https://git.openjdk.org/jdk/pull/20032#issuecomment-2217703027 From kbarrett at openjdk.org Tue Jul 9 13:14:37 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Jul 2024 13:14:37 GMT Subject: Integrated: 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 12:15:09 GMT, Kim Barrett wrote: > Please review this change to some jvmti tests, which were calling fflush with > an argument of 0. Most of these are in C++ code, where we change them to use > nullptr as the argument. A couple are in C, where we change them to use NULL. > This removes a bunch of -Wzero-as-null-pointer-constant when building with > that enabled. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 7e11fb70 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/7e11fb702696df733ca89d325200f2e9414402d9 Stats: 175 lines in 25 files changed: 0 ins; 0 del; 175 mod 8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests Reviewed-by: jwaters, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/20032 From simonis at openjdk.org Tue Jul 9 14:18:53 2024 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 Jul 2024 14:18:53 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3] In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Addressed @AlanBateman's suggestions and updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20011/files - new: https://git.openjdk.org/jdk/pull/20011/files/080999e1..5fb85533 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=01-02 Stats: 21 lines in 1 file changed: 6 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/20011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20011/head:pull/20011 PR: https://git.openjdk.org/jdk/pull/20011 From simonis at openjdk.org Tue Jul 9 14:18:53 2024 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 Jul 2024 14:18:53 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Tue, 9 Jul 2024 12:17:25 GMT, Alan Bateman wrote: >> @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? >> >> Thank you and best regards, >> Volker > >> @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? > > (Catching up as I was away for a few days). > > I agree it would be useful to have an API note on this topic. There were several reports of deadlocks, ClassCircularityError, and other hard to diagnose issues when support for instrumentation was originally introduced in JDK 5. I think agent maintainers learned to exclude many of the core classes in java.base but that is always a moving target and there have been a few more sightings/reports recently (maybe due to newer features doing more in Java rather than in the VM). > > I agree that the ClassFileTransformer class description is the best place for this. My initial reaction was to wonder about the j.l.instrument package description but it is more focused on starting agents and the JAR file attributes so I think your proposed location is best.. > > As regards the text then it might be better to start with a sentence to say that the "transform" method may be called from critical points in JDK core classes or called to transform JDK core classes. You've got some of this in second sentence but I think better to lead with it before revealing one of the several possible things that can happen. I think part of the lead in needs to say "great care must be taken" or something like that to get across the point that the ClassFileTransformer implementor has the potential to cause many possible issues. For the same class and linkage error then probably best to not use the phrase "transitively requires" as it's too close "requires transitive" used in module declarations. > > Note that the `@jvms` tag can be used to reference the JVMS section. You'll see a few examples in other classes. Thanks a lot for looking into this @AlanBateman. I've tried to integrate your suggestions into the new version of the PR. I already used the `@jvms` tag in the latest version of my PR based on @liach's suggestion. I also updated the other reference to the JVMS above the new `@apiNote` which didn't used the tag either (and was wrong because the JVMS sections have changed since Java 5 :) Please let me know if this sounds better now or if you see further room for improvement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2217856802 From kevinw at openjdk.org Tue Jul 9 18:28:17 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 18:28:17 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> References: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> Message-ID: On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. >> https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 >> >> >> if (getMethod().getName().asString().equals("wait") && >> getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { >> >> >> However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. >> >> I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". >> I confirmed that the lock information is correctly printed with this fix. >> I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. >> >> Would anyone review this change, please? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8335743: jhsdb jstack cannot print some information on the waiting thread Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20049#pullrequestreview-2167070972 From amenkov at openjdk.org Tue Jul 9 19:20:20 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 9 Jul 2024 19:20:20 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Tue, 9 Jul 2024 04:43:59 GMT, Chris Plummer wrote: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java line 356: > 354: } > 355: > 356: // We need to resume the main thread because thread2 might be blocked on it, This does not look correct to me. This is the last test scenario - thread2.resume should resumes the thread while vm is suspended. thread2 should not be blocked on main thread. Looking at the debuggee I suppose the blocking is possible during logging. I'd suggest to update the debugee and remove any logging between breakpoints 2 and 3 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1671037516 From kevinw at openjdk.org Tue Jul 9 19:42:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Jul 2024 19:42:19 GMT Subject: [jdk23] Integrated: 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range In-Reply-To: <7JorVYHv2FWSlD4ZQ3cEK_jQfKJweCJkH5jaNG_nsFw=.8e697bb4-260f-4ac6-bb86-6f6fb6e03f60@github.com> References: <7JorVYHv2FWSlD4ZQ3cEK_jQfKJweCJkH5jaNG_nsFw=.8e697bb4-260f-4ac6-bb86-6f6fb6e03f60@github.com> Message-ID: On Wed, 3 Jul 2024 08:24:43 GMT, Kevin Walls wrote: > Clean backport to jdk23 of a simple test update, to try and avoid spurious failures. This pull request has now been integrated. Changeset: 70ad622b Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/70ad622bc23fc5a1808466193fd6c7ea2f178ec9 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range Reviewed-by: cjplummer Backport-of: 79a3554e1da604627b3a010dc269c1bd914c79d3 ------------- PR: https://git.openjdk.org/jdk/pull/19999 From amenkov at openjdk.org Tue Jul 9 19:53:21 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 9 Jul 2024 19:53:21 GMT Subject: RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 08:39:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an incorrect entry from `ProblemList-Virtual.txt`? > > As noted in https://bugs.openjdk.org/browse/JDK-8335966 this entry is a left over which went unnoticed when we did the changes in https://bugs.openjdk.org/browse/JDK-8333130. > > The refactored test `NativeMethodPrefixApp` has been functioning without the errors for which `NativeMethodPrefixAgent` was previously problem listed. So I haven't replaced that problem list entry and instead have just removed it. > > `NativeMethodPrefixApp` is known to run into an intermittent timeout with virtual threads and that's tracked in https://bugs.openjdk.org/browse/JDK-8334167 and I think it's not problem listing worthy given the relatively low frequency of such timeouts. Furthermore, in the coming days, I plan to propose a change to this `NativeMethodPrefixApp` test which should fix the timeout failures. > > To verify that this removal doesn't cause any unexpected issues, I've triggered a CI run of the relevant tier. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20094#pullrequestreview-2167328097 From coleenp at openjdk.org Tue Jul 9 21:20:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 9 Jul 2024 21:20:21 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> Message-ID: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> On Mon, 8 Jul 2024 16:21:16 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Add JVMCI symbol exports > - Revert "More graceful JVMCI VM option interaction" > > This reverts commit 2814350370cf142e130fe1d38610c646039f976d. This is really great work, Axel! I've been reading this code for a while, and have done one pass looking through the PR with a few comments. src/hotspot/share/opto/library_call.cpp line 4620: > 4618: Node *unlocked_val = _gvn.MakeConX(markWord::unlocked_value); > 4619: Node *chk_unlocked = _gvn.transform(new CmpXNode(lmasked_header, unlocked_val)); > 4620: Node *test_not_unlocked = _gvn.transform(new BoolNode(chk_unlocked, BoolTest::ne)); I don't really know what this does. Someone from the c2 compiler group should look at this. src/hotspot/share/runtime/arguments.cpp line 1830: > 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); > 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); > 1830: } Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? src/hotspot/share/runtime/javaThread.inline.hpp line 258: > 256: } > 257: > 258: _om_cache.clear(); This could be shorter, ie: if (UseObjectMonitorTable) _om_cache.clear(); I think the not having an assert was to make the caller unconditional, which is good. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 393: > 391: > 392: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor(oop object, JavaThread* current, const ObjectSynchronizer::InflateCause cause, bool try_read) { > 393: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); This assert should be assert(UseObjectMonitorTable not LM_LIGHTWEIGHT). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 732: > 730: > 731: markWord mark = object->mark(); > 732: assert(!mark.is_unlocked(), "must be unlocked"); "must be locked" makes more sense. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763: > 761: assert(mark.has_monitor(), "must be"); > 762: // The monitor exists > 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current, object, mark); This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? Or we got here because BasicLock.metadata was not the ObjectMonitor? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 773: > 771: } > 772: > 773: ObjectMonitor* LightweightSynchronizer::inflate_locked_or_imse(oop obj, const ObjectSynchronizer::InflateCause cause, TRAPS) { I figured out at one point why we now check IMSE here but now cannot remember. Can you add a comment why above this function? ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2167461168 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671214948 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671216649 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671220251 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671225452 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671229697 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671231155 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671231863 From jpai at openjdk.org Wed Jul 10 01:36:36 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 Jul 2024 01:36:36 GMT Subject: RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 08:39:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an incorrect entry from `ProblemList-Virtual.txt`? > > As noted in https://bugs.openjdk.org/browse/JDK-8335966 this entry is a left over which went unnoticed when we did the changes in https://bugs.openjdk.org/browse/JDK-8333130. > > The refactored test `NativeMethodPrefixApp` has been functioning without the errors for which `NativeMethodPrefixAgent` was previously problem listed. So I haven't replaced that problem list entry and instead have just removed it. > > `NativeMethodPrefixApp` is known to run into an intermittent timeout with virtual threads and that's tracked in https://bugs.openjdk.org/browse/JDK-8334167 and I think it's not problem listing worthy given the relatively low frequency of such timeouts. Furthermore, in the coming days, I plan to propose a change to this `NativeMethodPrefixApp` test which should fix the timeout failures. > > To verify that this removal doesn't cause any unexpected issues, I've triggered a CI run of the relevant tier. Thank you Kevin and Alex for the reviews. tier5, where this problem listing file is in use, completed without issues. I will go ahead and integrate this in the next few hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20094#issuecomment-2219305134 From jpai at openjdk.org Wed Jul 10 03:33:24 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 Jul 2024 03:33:24 GMT Subject: Integrated: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 08:39:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes an incorrect entry from `ProblemList-Virtual.txt`? > > As noted in https://bugs.openjdk.org/browse/JDK-8335966 this entry is a left over which went unnoticed when we did the changes in https://bugs.openjdk.org/browse/JDK-8333130. > > The refactored test `NativeMethodPrefixApp` has been functioning without the errors for which `NativeMethodPrefixAgent` was previously problem listed. So I haven't replaced that problem list entry and instead have just removed it. > > `NativeMethodPrefixApp` is known to run into an intermittent timeout with virtual threads and that's tracked in https://bugs.openjdk.org/browse/JDK-8334167 and I think it's not problem listing worthy given the relatively low frequency of such timeouts. Furthermore, in the coming days, I plan to propose a change to this `NativeMethodPrefixApp` test which should fix the timeout failures. > > To verify that this removal doesn't cause any unexpected issues, I've triggered a CI run of the relevant tier. This pull request has now been integrated. Changeset: dcf4e0d5 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/dcf4e0d51f392afe2711223484e932e3826e8864 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/20094 From dholmes at openjdk.org Wed Jul 10 06:45:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Jul 2024 06:45:16 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> References: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> Message-ID: On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. >> https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 >> >> >> if (getMethod().getName().asString().equals("wait") && >> getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { >> >> >> However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. >> >> I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". >> I confirmed that the lock information is correctly printed with this fix. >> I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. >> >> Would anyone review this change, please? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8335743: jhsdb jstack cannot print some information on the waiting thread Update looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20049#pullrequestreview-2168167270 From cjplummer at openjdk.org Wed Jul 10 06:49:22 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 06:49:22 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Tue, 9 Jul 2024 19:17:26 GMT, Alex Menkov wrote: > This does not look correct to me. > This is the last test scenario - thread2.resume should resumes the thread while vm is suspended. > thread2 should not be blocked on main thread. > Looking at the debuggee I suppose the blocking is possible during logging. I'd suggest to update the debugee and remove any logging between breakpoints 2 and 3 It looks like the debuggee gets as far as the following: public void runt2() { log("method 'runt2' enter 1"); i1++; i2--; log("method 'run2t' exit"); return; } It prints the first log and hits a breakpoint setup on the 2nd line. The debugger resumes thread2 after this, but we never see the 2nd log. Whenever we see this failure, the following logs from the mainThread are always delayed (by a lot): debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject) { debugee.stderr> **> mainThread: waiting for an instruction from the debugger ... I think this delay is resulting in the the mainThread being in the middle of doing one of these logs when the vm.suspend() is done. This leaves mainThread suspended while holding a lock needed for doing logging (logging is just a simple System.err.prinln()). I'm trying to prove this by getting a debuggee thread dump when getting the 3rd Breakpoint event times out, but for some reason once I added this code I could no longer reproduce the problem (still trying though). I don't like the idea of avoiding this issue by getting rid of certain problematic logging. It seems error prone. Someone could add some new logging in the future. I'll see if there is a better solution than the vm.resume(). Perhaps I could just resume mainThread. However, I think with virtual threads I/O can be dependent on other threads like an "unparker" thread. Another solution might be to have the debugger and debuggee do an additional handshake so we can guarantee that mainThread is done with these two log statements. Currently when we get to the 2nd log statement, that just means the debuggee is waiting for a "quit" command from the debugger. We could at this point have the debuggee send a command to the debugger, and have the debugger wait for this command before it does the vm.suspend(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1671707426 From mbaesken at openjdk.org Wed Jul 10 07:18:15 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Jul 2024 07:18:15 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 12:52:34 GMT, Thomas Stuefe wrote: > Checked and Alpine processes have a [heap] segment. Could you try that? Yes there is an entry [heap] in the file column of the lengthy table. Do you think this is present on all Linux platforms? If I replace the vdso with [heap] maybe it breaks elsewhere ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2219736851 From duke at openjdk.org Wed Jul 10 08:57:16 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 10 Jul 2024 08:57:16 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> References: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> Message-ID: On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. >> https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 >> >> >> if (getMethod().getName().asString().equals("wait") && >> getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { >> >> >> However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. >> >> I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". >> I confirmed that the lock information is correctly printed with this fix. >> I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. >> >> Would anyone review this change, please? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8335743: jhsdb jstack cannot print some information on the waiting thread Thank you all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20049#issuecomment-2219939865 From duke at openjdk.org Wed Jul 10 08:57:17 2024 From: duke at openjdk.org (duke) Date: Wed, 10 Jul 2024 08:57:17 GMT Subject: RFR: 8335743: jhsdb jstack cannot print some information on the waiting thread [v2] In-Reply-To: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> References: <9JE6GE9kZMAOpcXV_ONLVy8_reVYNYLShy4qCdtJR8k=.dd24378f-8a1e-4407-b5c0-882c756ce493@github.com> Message-ID: On Mon, 8 Jul 2024 12:16:51 GMT, KIRIYAMA Takuya wrote: >> This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. >> >> When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. >> https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 >> >> >> if (getMethod().getName().asString().equals("wait") && >> getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { >> >> >> However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. >> >> I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". >> I confirmed that the lock information is correctly printed with this fix. >> I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. >> >> Would anyone review this change, please? > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8335743: jhsdb jstack cannot print some information on the waiting thread @tkiriyama Your change (at version 8ebc2b4b3740185dea6a66181d055ad3c4e43313) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20049#issuecomment-2219941120 From clanger at openjdk.org Wed Jul 10 09:20:40 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 10 Jul 2024 09:20:40 GMT Subject: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 Message-ID: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> The change of JDK-8294960 has brought an increase of required metaspace for this test on AIX which seems to go beyond 23m in most cases. So I propose another slight increment. Why AIX needs more metaspace compared to other platforms is probably a different topic. ------------- Commit messages: - JDK-8335533 Changes: https://git.openjdk.org/jdk/pull/20106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335533 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20106/head:pull/20106 PR: https://git.openjdk.org/jdk/pull/20106 From aboldtch at openjdk.org Wed Jul 10 09:46:13 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 09:46:13 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v4] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with five additional commits since the last revision: - Add comment LightweightSynchronizer::inflate_locked_or_imse - Fix BasicLock::object_monitor_cache() for other platforms - Update LightweightSynchronizer::exit assert - Update LightweightSynchronizer::get_or_insert_monitor assert - Update JavaThread::om_clear_monitor_cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/173b75b8..d12aa5f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=02-03 Stats: 23 lines in 3 files changed: 17 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Wed Jul 10 09:46:18 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 09:46:18 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Tue, 9 Jul 2024 20:44:58 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >> This reverts commit 2814350370cf142e130fe1d38610c646039f976d. > > src/hotspot/share/runtime/arguments.cpp line 1830: > >> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); >> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); >> 1830: } > > Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? Maybe. It boils down to what to do when the JVM receives `-XX:LockingMode={LM_LEGACY,LM_MONITOR} -XX:+UseObjectMonitorTable` The options I see are 1. Select `LockingMode=LM_LIGHTWEIGHT` 2. Select `UseObjectMonitorTable=false` 3. Do not start the VM Between 1. and 2. it is impossible to know what the real intentions were. But with being a newer `-XX:+UseObjectMonitorTable` it somehow seems more likely. Option 3. is probably the sensible solution, but it is hard to determine. We tend to not close the VM because of incompatible options, rather fix them. But I believe there are precedence for both. If we do this however we will have to figure out all the interactions with our testing framework. And probably add some safeguards. > src/hotspot/share/runtime/javaThread.inline.hpp line 258: > >> 256: } >> 257: >> 258: _om_cache.clear(); > > This could be shorter, ie: if (UseObjectMonitorTable) _om_cache.clear(); > I think the not having an assert was to make the caller unconditional, which is good. Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 393: > >> 391: >> 392: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor(oop object, JavaThread* current, const ObjectSynchronizer::InflateCause cause, bool try_read) { >> 393: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); > > This assert should be assert(UseObjectMonitorTable not LM_LIGHTWEIGHT). Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 732: > >> 730: >> 731: markWord mark = object->mark(); >> 732: assert(!mark.is_unlocked(), "must be unlocked"); > > "must be locked" makes more sense. Done. > This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? We could. > Or we got here because BasicLock.metadata was not the ObjectMonitor? That is one reason we got here. We also get here from C1/interpreter as well as if there are other threads on the entry queues. I think there was an assumption that it would not be that crucial in those cases. One off the reasons we do not read the `BasicLock` cache from the runtime is that we are not as careful with keeping the `BasicLock` initialised on platforms without `UseObjectMonitorTable`. The idea was that as long as they call into the VM, we do not need to keep it invariant. But this made me realise `BasicLock::print_on` will be broken on non x86/aarch64 platforms if running with `UseObjectMonitorTable`. Rather then fix all platforms I will condition BasicLock::object_monitor_cache to return nullptr on not supported platforms. Could add this then. Should probably add an overload to `ObjectSynchronizer::read_monitor` which takes the lock and push i all the way here. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 773: > >> 771: } >> 772: >> 773: ObjectMonitor* LightweightSynchronizer::inflate_locked_or_imse(oop obj, const ObjectSynchronizer::InflateCause cause, TRAPS) { > > I figured out at one point why we now check IMSE here but now cannot remember. Can you add a comment why above this function? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959198 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959362 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959515 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959614 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959763 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1671959852 From j.bachorik at gmail.com Wed Jul 10 15:37:27 2024 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Wed, 10 Jul 2024 17:37:27 +0200 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: On Mon, Jul 8, 2024 at 11:19?AM Alan Bateman wrote: > On 03/07/2024 11:26, Thiago Henrique Hupner wrote: > > Dear JDK developers, > > > > I'd like to propose adding an option that allows the JVM to ignore a > > non-existent -javaagent instead of aborting. > > > > Currently, if a -javaagent is specified but the agent jar file doesn't > > exist, the JVM aborts with an error. This can cause issues in > > environments where the same JVM arguments are used across different > > systems, but not all systems have the agent installed. > > In general you can't assume that the same VM options or arguments to the > java launcher can be used across different systems, different JDK > releases, or in this case specifying a tool agent that may not be > installed or may be installed in a different location. For this case it > may be better to re-visit the launch script for the application so that > it conditionally adds the -javaagent option when the tool agent is needed. > This may not always be possible. Some systems have rather complex and inlexible launchers - for example Apache Spark with its clusters, drivers and executors and automatic distribution of resources. For that system, if one needs to add an on-startup Java agent via `-javaagent` option the only way is to modify the setup which will add `-javaagent` to all components, pointing to a location where the resource distribution service should be putting the agent jar. However, mistakes happen and the jar may not be there. But because usually the agent is providing tracing or metrics collection, which are all optional, it is not feasible to hard-crash the Java process because of not being able to load the Java agent. Forn this PoV the proposal to allow optionally ignoring non-existing Java agent sounds as a very pragmatic solution, -JB- > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jul 10 15:53:43 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Jul 2024 16:53:43 +0100 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: <1b81179e-6d61-4a61-a1f5-6c178a437b1b@oracle.com> On 10/07/2024 16:37, Jaroslav Bachorik wrote: > : > > This may not always be possible. Some systems have rather complex and > inlexible launchers - for example Apache Spark with its clusters, > drivers and executors and automatic distribution of resources. For > that system, if one needs to add an on-startup Java agent via > `-javaagent` option the only way is to modify the setup which will add > `-javaagent` to all components, pointing to a location where the > resource distribution service should be putting the agent jar. > However, mistakes happen and the jar may not be there. But because > usually the agent is providing tracing or metrics collection, which > are all optional, it is not feasible to hard-crash the Java process > because of not being able to load the Java agent. > > Forn this PoV the proposal to allow optionally ignoring non-existing > Java agent sounds as a very pragmatic solution, > The issue of injecting CLI options to start tool agents was explored back in JSR 163, that is the reason for environment variables such as JAVA_TOOL_OPTIONS. Broader support was added in JDK 9 with JDK_JAVA_OPTIONS, @argfile support, and support for GNU style options. So the JDK has several features to augment the command line or options. Has anyone tried to work with the Apache Spark (or other projects) to make use of any of this support so that additional CLI options are conditionally used? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Wed Jul 10 20:07:43 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Jul 2024 20:07:43 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: <02BrY3fuoulbz4OStQqRA2sEAjYcxNlyv-kBuVJvH4o=.a2bc9843-3132-45f1-82fc-48a730abc5a7@github.com> On Wed, 10 Jul 2024 07:15:38 GMT, Matthias Baesken wrote: > > Checked and Alpine processes have a [heap] segment. Could you try that? > > Yes there is an entry [heap] in the file column of the lengthy table. Do you think this is present on all Linux platforms? If I replace the vdso with [heap] maybe it breaks elsewhere ? Should be. It is the brk segment. I see it on Linux x64, x86, armv7, armv8 and x64 Alpine. Otherwise, just make the [vdso] dependent on !Alpine. That would work, too. Up to you. I just don't want to completely avoid testing for OS-side segments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2220282709 From cjplummer at openjdk.org Wed Jul 10 20:07:46 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 20:07:46 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Wed, 10 Jul 2024 06:46:56 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java line 356: >> >>> 354: } >>> 355: >>> 356: // We need to resume the main thread because thread2 might be blocked on it, >> >> This does not look correct to me. >> This is the last test scenario - thread2.resume should resumes the thread while vm is suspended. >> thread2 should not be blocked on main thread. >> Looking at the debuggee I suppose the blocking is possible during logging. I'd suggest to update the debugee and remove any logging between breakpoints 2 and 3 > >> This does not look correct to me. >> This is the last test scenario - thread2.resume should resumes the thread while vm is suspended. >> thread2 should not be blocked on main thread. >> Looking at the debuggee I suppose the blocking is possible during logging. I'd suggest to update the debugee and remove any logging between breakpoints 2 and 3 > > It looks like the debuggee gets as far as the following: > > > public void runt2() { > log("method 'runt2' enter 1"); > i1++; > i2--; > log("method 'run2t' exit"); > return; > } > > > It prints the first log and hits a breakpoint setup on the 2nd line. The debugger resumes thread2 after this, but we never see the 2nd log. Whenever we see this failure, the following logs from the mainThread are always delayed (by a lot): > > > debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject) { > debugee.stderr> **> mainThread: waiting for an instruction from the debugger ... > > > I think this delay is resulting in the the mainThread being in the middle of doing one of these logs when the vm.suspend() is done. This leaves mainThread suspended while holding a lock needed for doing logging (logging is just a simple System.err.prinln()). I'm trying to prove this by getting a debuggee thread dump when getting the 3rd Breakpoint event times out, but for some reason once I added this code I could no longer reproduce the problem (still trying though). > > I don't like the idea of avoiding this issue by getting rid of certain problematic logging. It seems error prone. Someone could add some new logging in the future. I'll see if there is a better solution than the vm.resume(). Perhaps I could just resume mainThread. However, I think with virtual threads I/O can be dependent on other threads like an "unparker" thread. > > Another solution might be to have the debugger and debuggee do an additional handshake so we can guarantee that mainThread is done with these two log statements. Currently when we get to the 2nd log statement, that just means the debuggee is waiting for a "quit" command from the debugger. We could at this point have the debuggee send a command to the debugger, and have the debugger wait for this command before it does the vm.suspend(). I was finally able to reproduce the issue with the stack dumping support in place. mainThread is in the middle of printing the 1st of the two logs mention above. mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1672682495 From mbaesken at openjdk.org Wed Jul 10 20:07:45 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Jul 2024 20:07:45 GMT Subject: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 In-Reply-To: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> References: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> Message-ID: <79g6v7kUm7q47w3_4_g5ZZ_dxC7xH1zZfml2V7izK0s=.cb57005c-f87f-47b4-ba74-16ae48f23e76@github.com> On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for this test on AIX which seems to go beyond 23m in most cases. So I propose another slight increment. > > Why AIX needs more metaspace compared to other platforms is probably a different topic. LGTM ; I observed a very small increase on Linux x86_64 too but not enough to 'break' the metaspace test settings on this platform. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20106#pullrequestreview-2168788816 From stuefe at openjdk.org Wed Jul 10 20:07:46 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Jul 2024 20:07:46 GMT Subject: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 In-Reply-To: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> References: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> Message-ID: On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for this test on AIX which seems to go beyond 23m in most cases. So I propose another slight increment. > > Why AIX needs more metaspace compared to other platforms is probably a different topic. +1 There is nothing I know off-hand that would be AIX-specific. Or is it PPC-specific? If the latter, does the delta go away with -Xint, or if you only run with C1? Other than that, to analyze the problem, I would stop the test on a defined point on both a good platform and AIX, and do: `jcmd VM.metaspace show-loaders show-classes` and maybe also start the tests with `-Xlog:metaspace=trace` and attach the results to the JBS issue. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20106#pullrequestreview-2168811479 PR Comment: https://git.openjdk.org/jdk/pull/20106#issuecomment-2220262077 From stuefe at openjdk.org Wed Jul 10 20:07:48 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Jul 2024 20:07:48 GMT Subject: RFR: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 In-Reply-To: References: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> Message-ID: <80C5D0X5Zb6CcbQP0URvsvCKFunXa2lZTL17TGZh9PE=.24c128b7-61af-4308-823d-02f13a534f1c@github.com> On Wed, 10 Jul 2024 11:24:14 GMT, Thomas Stuefe wrote: > There is nothing I know off-hand that would be AIX-specific. Or is it PPC-specific? If the latter, does the delta go away with -Xint, or if you only run with C1? > > Other than that, to analyze the problem, I would stop the test on a defined point on both a good platform and AIX, and do: > > `jcmd VM.metaspace show-loaders show-classes` and maybe also start the tests with `-Xlog:metaspace=trace` > > and attach the results to the JBS issue. resp. open a new issue, if this issue is just about increasing the metaspace limit ------------- PR Comment: https://git.openjdk.org/jdk/pull/20106#issuecomment-2220263896 From aboldtch at openjdk.org Wed Jul 10 20:10:07 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Jul 2024 20:10:07 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object - Fix typos - Remove unused variable - Add missing inline qualifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/d12aa5f6..a207544b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=03-04 Stats: 16 lines in 3 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From simonis at openjdk.org Wed Jul 10 20:10:13 2024 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 10 Jul 2024 20:10:13 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v4] In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Addressed @AlanBateman's new suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20011/files - new: https://git.openjdk.org/jdk/pull/20011/files/5fb85533..f8429bc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20011&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20011/head:pull/20011 PR: https://git.openjdk.org/jdk/pull/20011 From alanb at openjdk.org Wed Jul 10 20:10:24 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Jul 2024 20:10:24 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Tue, 9 Jul 2024 14:18:53 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Addressed @AlanBateman's suggestions and updated copyright year src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 158: > 156: * > 157: *

> 158: * Note the term class file is used as defined in section {@jvms 4} The The existing sentence uses "section" but I assume it should be "Chapter". src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 167: > 165: * same time required during the transformation process as this can lead to class > 166: * circularity or linkage errors. Using bytecode transformation libraries which depend > 167: * on core JDK class can increase the risk of such errors. It's probably impossible to create a BCI library that don't depend on JDK core classes so maybe it would be better to drop the second sentence. src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 179: > 177: * This means that a {@link LinkageError} triggered during transformation of > 178: * {@code C} in a class {@code D} not directly related to {@code C} can repeatedly > 179: * occur later in arbitrary user code which uses {@code D}. This paragraph looks okay but I can't help thinking we should have something in normative text to reference that specifies the reentrancy behavior. Maybe I missed it but I thought we have something in the API docs on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672215548 PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672219986 PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672255885 From simonis at openjdk.org Wed Jul 10 20:10:26 2024 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 10 Jul 2024 20:10:26 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Wed, 10 Jul 2024 12:53:46 GMT, Alan Bateman wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed @AlanBateman's suggestions and updated copyright year > > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 158: > >> 156: * >> 157: *

>> 158: * Note the term class file is used as defined in section {@jvms 4} The > > The existing sentence uses "section" but I assume it should be "Chapter". Correct, it was section 3.1 before but now it's chapter 4. Fixed. > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 167: > >> 165: * same time required during the transformation process as this can lead to class >> 166: * circularity or linkage errors. Using bytecode transformation libraries which depend >> 167: * on core JDK class can increase the risk of such errors. > > It's probably impossible to create a BCI library that don't depend on JDK core classes so maybe it would be better to drop the second sentence. Fixed. > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 179: > >> 177: * This means that a {@link LinkageError} triggered during transformation of >> 178: * {@code C} in a class {@code D} not directly related to {@code C} can repeatedly >> 179: * occur later in arbitrary user code which uses {@code D}. > > This paragraph looks okay but I can't help thinking we should have something in normative text to reference that specifies the reentrancy behavior. Maybe I missed it but I thought we have something in the API docs on this. I haven't found anything either. The only specification-relevant mentioning of the issue I found is in the [JVMTI Specification](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) referenced at the beginning of the PR: > Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes. The example that follows describes an infinite recursion when instrumenting the the `j.l.Object()` constructor. I think the exact reentrancy behavior isn't specified anywhere. Not even the exact that should be thrown in such a case is specified (see [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165) for a discussion of different scenarios). I think the real problem is that the JVMS predates the JVMTI specification and the interaction between instrumentation and class loading isn't clearly defined. I think it might even be possible to treat class loading errors during transformation differently, such that they will not lead to a permanent resolution error for the corresponding constant pool entries. I know that this will violate the current section ? 5.4.3 Resolution (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3) of the JVM specification which mandates that "if an attempt by the Java Virtual Machine to resolve a symbolic reference fails because an error is thrown that is an instance of LinkageError (or a subclass), then subsequent attempts to resolve the reference always fail with the same error that was thrown as a result of the initial resolution attempt". But as I wrote, that predates JVMTI and when JVMTI was added, we missed the opportunity to specify its exact impact on class loading an d resolution. But all this is a much bigger discussion. Maybe we should open another issue for it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672636821 PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672637843 PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1672663335 From ayang at openjdk.org Wed Jul 10 20:29:37 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Jul 2024 20:29:37 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: > Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. > > The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. > > Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. Albert Mingkun Yang 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 - Merge branch 'master' into pgc-vm-operation - pgc-vm-operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20077/files - new: https://git.openjdk.org/jdk/pull/20077/files/a7c69102..1d10dd5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=01-02 Stats: 1388 lines in 122 files changed: 508 ins; 309 del; 571 mod Patch: https://git.openjdk.org/jdk/pull/20077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20077/head:pull/20077 PR: https://git.openjdk.org/jdk/pull/20077 From zgu at openjdk.org Wed Jul 10 20:29:40 2024 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 10 Jul 2024 20:29:40 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 16:31:43 GMT, Albert Mingkun Yang wrote: >> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. >> >> The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. >> >> Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > pgc-vm-operation I really like this refactor, that brings parallel close to other GCs. Just a few nits, otherwise, LGTM src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 273: > 271: > 272: bool is_tlab = false; > 273: return mem_allocate_work(size, is_tlab, gc_overhead_limit_was_exceeded); Suggest: `return mem_allocate_work(size, false /* is_tlab */, gc_overhead_limit_was_exceeded);` src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 478: > 476: > 477: const bool clear_all_soft_refs = true; > 478: do_full_collection_no_gc_locker(clear_all_soft_refs); Suggest: not define `const bool clear_all_soft_refs = true;` and do `do_full_collection_no_gc_locker(true /* clear_all_soft_refs */);` instead src/hotspot/share/gc/parallel/psVMOperations.cpp line 68: > 66: > 67: GCCauseSetter gccs(heap, _gc_cause); > 68: heap->try_collect_at_safepoint(is_cause_full(_gc_cause)); can be simplified to `heap->try_collect_at_safepoint(_full);` ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20077#pullrequestreview-2166570482 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1670678592 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1671439533 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1672170373 From cjplummer at openjdk.org Wed Jul 10 20:43:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 20:43:57 GMT Subject: RFR: 8207908: JMXStatusTest.java fails assertion intermittently In-Reply-To: References: Message-ID: <6ztLJGdO276EPGtFWS7zgJHeRnVNX5o3RRimPGDGXvs=.ffc50758-9984-448e-b6c3-d1e84f279a95@github.com> On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and than its regexes can handle. > > Using the PID to match only the wanted process, my batches of 25 tests at the same time run in parallel without failure. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20037#pullrequestreview-2170245406 From cjplummer at openjdk.org Wed Jul 10 20:51:56 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 20:51:56 GMT Subject: RFR: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote: > The test test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java should be removed. > > This test was added when 6984520 was fixed in 6u25. It has been problemlisted since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it just wanted something "RMI" to connect with). > > Looking at the change it tested, the code is no longer the same, and is no longer at risk of this NPE. > > The original NPE fix was to check that jxmServerviceURL was not null before calling methods on it, but the current RMIConnector.java does not make those same calls. > > It is best to remove the test and its problemlist entry. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20054#pullrequestreview-2170267350 From cjplummer at openjdk.org Wed Jul 10 20:52:58 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 20:52:58 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Wed, 10 Jul 2024 17:10:46 GMT, Chris Plummer wrote: >>> This does not look correct to me. >>> This is the last test scenario - thread2.resume should resumes the thread while vm is suspended. >>> thread2 should not be blocked on main thread. >>> Looking at the debuggee I suppose the blocking is possible during logging. I'd suggest to update the debugee and remove any logging between breakpoints 2 and 3 >> >> It looks like the debuggee gets as far as the following: >> >> >> public void runt2() { >> log("method 'runt2' enter 1"); >> i1++; >> i2--; >> log("method 'run2t' exit"); >> return; >> } >> >> >> It prints the first log and hits a breakpoint setup on the 2nd line. The debugger resumes thread2 after this, but we never see the 2nd log. Whenever we see this failure, the following logs from the mainThread are always delayed (by a lot): >> >> >> debugee.stderr> **> mainThread: mainThread is out of: synchronized (lockingObject) { >> debugee.stderr> **> mainThread: waiting for an instruction from the debugger ... >> >> >> I think this delay is resulting in the the mainThread being in the middle of doing one of these logs when the vm.suspend() is done. This leaves mainThread suspended while holding a lock needed for doing logging (logging is just a simple System.err.prinln()). I'm trying to prove this by getting a debuggee thread dump when getting the 3rd Breakpoint event times out, but for some reason once I added this code I could no longer reproduce the problem (still trying though). >> >> I don't like the idea of avoiding this issue by getting rid of certain problematic logging. It seems error prone. Someone could add some new logging in the future. I'll see if there is a better solution than the vm.resume(). Perhaps I could just resume mainThread. However, I think with virtual threads I/O can be dependent on other threads like an "unparker" thread. >> >> Another solution might be to have the debugger and debuggee do an additional handshake so we can guarantee that mainThread is done with these two log statements. Currently when we get to the 2nd log statement, that just means the debuggee is waiting for a "quit" command from the debugger. We could at this point have the debuggee send a command to the debugger, and have the debugger wait for this command before it does the vm.suspend(). > > I was finally able to reproduce the issue with the stack dumping support in place. mainThread is in the middle of printing the 1st of the two logs mention above. mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. I was able to add synchronization between the debugger and debuggee to fix this issue, but I don't really like the solution. It just adds more complexity and makes the test even harder to follow. What I'd like to do is just put a short sleep in before the vm.suspend(). Let me know if you think this is ok and I'll update the PR with the changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1672976958 From amenkov at openjdk.org Wed Jul 10 20:58:56 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 10 Jul 2024 20:58:56 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Wed, 10 Jul 2024 20:50:50 GMT, Chris Plummer wrote: >> I was finally able to reproduce the issue with the stack dumping support in place. mainThread is in the middle of printing the 1st of the two logs mention above. mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. > > I was able to add synchronization between the debugger and debuggee to fix this issue, but I don't really like the solution. It just adds more complexity and makes the test even harder to follow. What I'd like to do is just put a short sleep in before the vm.suspend(). Let me know if you think this is ok and I'll update the PR with the changes. Thank you for the confirming the reason of the timeout. To be more clear about my point: The test has 3 scenarios (see the test description): ThreadReference.resume() resumes the thread suspended with: * - with thread2.suspend()
* - at a breakpoint
* - with VirtualMachine.suspend()
So for 3rd scenario we should not call vm.resume() (as it converts 3rd scenario to 1st scenario). The test can be fixed by different ways, to me remove logging between breakpoint2 and breakpoint3 is the simplest way. Note that breakpoint2 is "runt2(), line 2" and breakpoint3 is "runt1(), line 7", there are 2 log statements. We can move breakpoint 3 to "runt2(), line 3" (I don't see much sense to have breakpoint 3 so far from breakpoint2 - we just need to ensure the thread was resumed ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1672989677 From amenkov at openjdk.org Wed Jul 10 21:03:55 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 10 Jul 2024 21:03:55 GMT Subject: RFR: 8207908: JMXStatusTest.java fails assertion intermittently In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and than its regexes can handle. > > Using the PID to match only the wanted process, my batches of 25 tests at the same time run in parallel without failure. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20037#pullrequestreview-2170309586 From kevinw at openjdk.org Wed Jul 10 21:26:56 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 10 Jul 2024 21:26:56 GMT Subject: RFR: 8207908: JMXStatusTest.java fails assertion intermittently In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and than its regexes can handle. > > Using the PID to match only the wanted process, my batches of 25 tests at the same time run in parallel without failure. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20037#issuecomment-2221516370 From cjplummer at openjdk.org Wed Jul 10 21:31:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 21:31:55 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Wed, 10 Jul 2024 20:56:17 GMT, Alex Menkov wrote: >> I was able to add synchronization between the debugger and debuggee to fix this issue, but I don't really like the solution. It just adds more complexity and makes the test even harder to follow. What I'd like to do is just put a short sleep in before the vm.suspend(). Let me know if you think this is ok and I'll update the PR with the changes. > > Thank you for the confirming the reason of the timeout. > > To be more clear about my point: > The test has 3 scenarios (see the test description): > ThreadReference.resume() resumes the thread suspended with: > * - with thread2.suspend()
> * - at a breakpoint
> * - with VirtualMachine.suspend()
> > So for 3rd scenario we should not call vm.resume() (as it converts 3rd scenario to 1st scenario). > The test can be fixed by different ways, to me remove logging between breakpoint2 and breakpoint3 is the simplest way. > Note that breakpoint2 is "runt2(), line 2" and breakpoint3 is "runt1(), line 7", there are 2 log statements. We can move breakpoint 3 to "runt2(), line 3" (I don't see much sense to have breakpoint 3 so far from breakpoint2 - we just need to ensure the thread was resumed ) Removing log() statements to fix the problem can be risky because someone could re-add them in the future. What about my idea of doing a short sleep before the vm.suspend() to make sure the main thread has advanced to the pipe.readln(), and won't be doing any more log calls until it gets the next command from the debugger (which should be "quit"). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673049995 From dcubed at openjdk.org Wed Jul 10 22:31:54 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 Jul 2024 22:31:54 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> On Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer wrote: >> Thank you for the confirming the reason of the timeout. >> >> To be more clear about my point: >> The test has 3 scenarios (see the test description): >> ThreadReference.resume() resumes the thread suspended with: >> * - with thread2.suspend()
>> * - at a breakpoint
>> * - with VirtualMachine.suspend()
>> >> So for 3rd scenario we should not call vm.resume() (as it converts 3rd scenario to 1st scenario). >> The test can be fixed by different ways, to me remove logging between breakpoint2 and breakpoint3 is the simplest way. >> Note that breakpoint2 is "runt2(), line 2" and breakpoint3 is "runt1(), line 7", there are 2 log statements. We can move breakpoint 3 to "runt2(), line 3" (I don't see much sense to have breakpoint 3 so far from breakpoint2 - we just need to ensure the thread was resumed ) > > Removing log() statements to fix the problem can be risky because someone could re-add them in the future. What about my idea of doing a short sleep before the vm.suspend() to make sure the main thread has advanced to the pipe.readln(), and won't be doing any more log calls until it gets the next command from the debugger (which should be "quit"). Adding a `sleep()` between two statements does not scale when the test in question is under different loads or run with different options. All it will do is make a hang more rare (and frustrating to analyze). We do use short sleeps when we are in a while-loop checking on a condition of some sort that indicates that the "thing" for which we are waiting to happen has happened. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673123705 From cjplummer at openjdk.org Wed Jul 10 23:11:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Jul 2024 23:11:54 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Wed, 10 Jul 2024 22:29:08 GMT, Daniel D. Daugherty wrote: >> Removing log() statements to fix the problem can be risky because someone could re-add them in the future. What about my idea of doing a short sleep before the vm.suspend() to make sure the main thread has advanced to the pipe.readln(), and won't be doing any more log calls until it gets the next command from the debugger (which should be "quit"). > > Adding a `sleep()` between two statements does not scale when the test in > question is under different loads or run with different options. All it will do > is make a hang more rare (and frustrating to analyze). > > We do use short sleeps when we are in a while-loop checking on a condition > of some sort that indicates that the "thing" for which we are waiting to happen > has happened. I believe we've done quite a few short sleeps like this in the past. Scaling is not really an issue. It should only require at most a few ms, even with -Xcomp, so we wait 1000ms and then never have to think about the timing again. This test is ugly. Sometimes you have to fight ugly with ugly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673154099 From dholmes at openjdk.org Thu Jul 11 01:59:56 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Jul 2024 01:59:56 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Wed, 10 Jul 2024 23:09:05 GMT, Chris Plummer wrote: >> Adding a `sleep()` between two statements does not scale when the test in >> question is under different loads or run with different options. All it will do >> is make a hang more rare (and frustrating to analyze). >> >> We do use short sleeps when we are in a while-loop checking on a condition >> of some sort that indicates that the "thing" for which we are waiting to happen >> has happened. > > I believe we've done quite a few short sleeps like this in the past. Scaling is not really an issue. It should only require at most a few ms, even with -Xcomp, so we wait 1000ms and then never have to think about the timing again. This test is ugly. Sometimes you have to fight ugly with ugly. > mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. The classic example of why suspension is fraught with peril - the target must be guaranteed not to be holding any resource needed by the suspender. I think removing the logging may be the best bet here - with comments in the code to ensure someone does not add it back. Or else use a more primitive (native?) mechanism to do the logging, not System.out.println(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673290543 From duke at openjdk.org Thu Jul 11 02:47:02 2024 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 11 Jul 2024 02:47:02 GMT Subject: Integrated: 8335743: jhsdb jstack cannot print some information on the waiting thread In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 09:23:21 GMT, KIRIYAMA Takuya wrote: > This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161. > > When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. > https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 > > > if (getMethod().getName().asString().equals("wait") && > getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { > > > However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. > > I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". > I confirmed that the lock information is correctly printed with this fix. > I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. > > Would anyone review this change, please? This pull request has now been integrated. Changeset: d6c6847e Author: KIRIYAMA Takuya Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/d6c6847e32673d36a1958cefd1851ec9f3b1e2ad Stats: 25 lines in 4 files changed: 18 ins; 0 del; 7 mod 8335743: jhsdb jstack cannot print some information on the waiting thread Reviewed-by: dholmes, cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/20049 From jpai at openjdk.org Thu Jul 11 03:51:15 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 03:51:15 GMT Subject: [jdk23] RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Message-ID: I would like to backport this test-only change into `jdk23`. This cleans up the incorrect problem listing that was caused by a change that we introduced in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130. This is a clean backport of the commit that was integrated into master branch through https://github.com/openjdk/jdk/pull/20094. ------------- Commit messages: - Backport dcf4e0d51f392afe2711223484e932e3826e8864 Changes: https://git.openjdk.org/jdk/pull/20132/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335966 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20132/head:pull/20132 PR: https://git.openjdk.org/jdk/pull/20132 From cjplummer at openjdk.org Thu Jul 11 04:46:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 04:46:55 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Thu, 11 Jul 2024 01:57:33 GMT, David Holmes wrote: >> I believe we've done quite a few short sleeps like this in the past. Scaling is not really an issue. It should only require at most a few ms, even with -Xcomp, so we wait 1000ms and then never have to think about the timing again. This test is ugly. Sometimes you have to fight ugly with ugly. > >> mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. > > The classic example of why suspension is fraught with peril - the target must be guaranteed not to be holding any resource needed by the suspender. I think removing the logging may be the best bet here - with comments in the code to ensure someone does not add it back. Or else use a more primitive (native?) mechanism to do the logging, not System.out.println(). Which logging should be removed? Alex suggest the logging between breakpoints 2 and 3, but even that is not enough. There is logging after breakpoint 3, and that happens before the vm.resume() is done. I'm not saying this can't be done right, but I think pruning out logging like this in order to fix the problem not only removes some valuable logging from the test, but still leaves us open to this type of issue. I think the safer thing to do is to make sure mainThread is no longer logging (or will attempt to log) when the vmsuspend is done. This could be done by pruning some of its logging, but that has the same negatives as removing some thread2 logging. My sleep suggestion is by far the simplest. The "purist" fix would probably be the checkpoint approach (don't do the vm.suspend until mainThread has reached a stable point). That ended up getting a bit uglier than I had hoped, but I can finish up the work so you can have a look at it if you'd like. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673391953 From dholmes at openjdk.org Thu Jul 11 07:15:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Jul 2024 07:15:55 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Thu, 11 Jul 2024 04:43:49 GMT, Chris Plummer wrote: >>> mainThead is suspended and is holding a println related lock, and thread2 is stuck on the 2nd log call in runt2 awaiting the same lock. >> >> The classic example of why suspension is fraught with peril - the target must be guaranteed not to be holding any resource needed by the suspender. I think removing the logging may be the best bet here - with comments in the code to ensure someone does not add it back. Or else use a more primitive (native?) mechanism to do the logging, not System.out.println(). > > Which logging should be removed? Alex suggest the logging between breakpoints 2 and 3, but even that is not enough. There is logging after breakpoint 3, and that happens before the vm.resume() is done. I'm not saying this can't be done right, but I think pruning out logging like this in order to fix the problem not only removes some valuable logging from the test, but still leaves us open to this type of issue. > > I think the safer thing to do is to make sure mainThread is no longer logging (or will attempt to log) when the vmsuspend is done. This could be done by pruning some of its logging, but that has the same negatives as removing some thread2 logging. My sleep suggestion is by far the simplest. The "purist" fix would probably be the checkpoint approach (don't do the vm.suspend until mainThread has reached a stable point). That ended up getting a bit uglier than I had hoped, but I can finish up the work so you can have a look at it if you'd like. Sorry I'm unclear on the different threads involved here. IIUC the vm.suspend comes from the debugger, and the mainthread and thread-2 are both threads in the debuggee, being suspended at different times? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673522390 From kevinw at openjdk.org Thu Jul 11 07:32:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 07:32:00 GMT Subject: Integrated: 8207908: JMXStatusTest.java fails assertion intermittently In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote: > Test failure, reproducible running batches of tests at the same time on the same machine. > The use of "jcmd TestApp ..." gathers more output than the test wants and than its regexes can handle. > > Using the PID to match only the wanted process, my batches of 25 tests at the same time run in parallel without failure. This pull request has now been integrated. Changeset: b7d0eff5 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/b7d0eff5ad77e338b237773d2fc047eea3d2ac12 Stats: 9 lines in 2 files changed: 1 ins; 2 del; 6 mod 8207908: JMXStatusTest.java fails assertion intermittently Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/20037 From kevinw at openjdk.org Thu Jul 11 07:45:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 07:45:55 GMT Subject: [jdk23] RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: <2-TGBggmdoNHNF-OyQy-1F9nCcIcQf69oBVMBMaC6E8=.32c06622-ad0e-4381-8881-7b322d174076@github.com> On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote: > I would like to backport this test-only change into `jdk23`. This cleans up the incorrect problem listing that was caused by a change that we introduced in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130. > > This is a clean backport of the commit that was integrated into master branch through https://github.com/openjdk/jdk/pull/20094. looks good ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20132#pullrequestreview-2171159068 From jpai at openjdk.org Thu Jul 11 08:22:59 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 08:22:59 GMT Subject: [jdk23] RFR: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote: > I would like to backport this test-only change into `jdk23`. This cleans up the incorrect problem listing that was caused by a change that we introduced in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130. > > This is a clean backport of the commit that was integrated into master branch through https://github.com/openjdk/jdk/pull/20094. Thank you Kevin for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20132#issuecomment-2222320049 From jpai at openjdk.org Thu Jul 11 08:23:00 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Jul 2024 08:23:00 GMT Subject: [jdk23] Integrated: 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 03:45:38 GMT, Jaikiran Pai wrote: > I would like to backport this test-only change into `jdk23`. This cleans up the incorrect problem listing that was caused by a change that we introduced in JDK 23 as part of https://bugs.openjdk.org/browse/JDK-8333130. > > This is a clean backport of the commit that was integrated into master branch through https://github.com/openjdk/jdk/pull/20094. This pull request has now been integrated. Changeset: 6720685a Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/6720685abdc1c91f5083255782810cdb2d7d72f4 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt Reviewed-by: kevinw Backport-of: dcf4e0d51f392afe2711223484e932e3826e8864 ------------- PR: https://git.openjdk.org/jdk/pull/20132 From yzheng at openjdk.org Thu Jul 11 09:29:00 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 11 Jul 2024 09:29:00 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 20:10:07 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: > > - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object > - Fix typos > - Remove unused variable > - Add missing inline qualifiers src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 843: > 841: movptr(monitor, Address(box, BasicLock::object_monitor_cache_offset_in_bytes())); > 842: // null check with ZF == 0, no valid pointer below alignof(ObjectMonitor*) > 843: cmpptr(monitor, alignof(ObjectMonitor*)); Is this only for keeping `ZF == 0` and can be replaced by `test; je` if we are not using `jne` to jump to the slow path? Or is there any performance concern? Btw, I think `ZF` is always rewritten before entering into the slow path https://github.com/openjdk/jdk/blob/b32e4a68bca588d908bd81a398eb3171a6876dc5/src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp#L98-L102 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673704482 From aboldtch at openjdk.org Thu Jul 11 10:41:57 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Jul 2024 10:41:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v5] In-Reply-To: References: Message-ID: <50LctfChrqd3_HlWrKZKsq4gADeTHWqY1SuFMSwzpL4=.6c6df72a-9bdd-4390-a38d-5d1ee95b8543@github.com> On Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object >> - Fix typos >> - Remove unused variable >> - Add missing inline qualifiers > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 843: > >> 841: movptr(monitor, Address(box, BasicLock::object_monitor_cache_offset_in_bytes())); >> 842: // null check with ZF == 0, no valid pointer below alignof(ObjectMonitor*) >> 843: cmpptr(monitor, alignof(ObjectMonitor*)); > > Is this only for keeping `ZF == 0` and can be replaced by `test; je` if we are not using `jne` to jump to the slow path? Or is there any performance concern? Btw, I think `ZF` is always rewritten before entering into the slow path https://github.com/openjdk/jdk/blob/b32e4a68bca588d908bd81a398eb3171a6876dc5/src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp#L98-L102 You are correct the condition flag is not important here. At some point we had more than just `nullptr` and and `ObjectMonitor*` values, but also some small signal values which allowed us to move some slow path code into the runtime. When this was removed I just made the checks do the same on both aarch64 and x86. (Where aarch64 does not have a stub and jumps directly to the continuation requiring the correct condition flags after the branch.) _Side note: This might be something that will be explored further in the future. And allow to move a lot of the LM_LIGHTWEIGHT slow path code away from the lock node and code stub into the runtime._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673800250 From mbaesken at openjdk.org Thu Jul 11 12:30:29 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Jul 2024 12:30:29 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 [v2] In-Reply-To: References: Message-ID: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: test for heap segment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20072/files - new: https://git.openjdk.org/jdk/pull/20072/files/3c9d1b9e..c379a443 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20072&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20072&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20072/head:pull/20072 PR: https://git.openjdk.org/jdk/pull/20072 From mbaesken at openjdk.org Thu Jul 11 12:30:29 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Jul 2024 12:30:29 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: <0VELDzsDgPdM2PbaK52qG4lJAu_XUE8ymd1jMXqZzUY=.530ee86e-d9ff-4598-9300-2b49e728f49f@github.com> On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. Hi Thomas, I added a check for the [heap] segment . ------------- PR Comment: https://git.openjdk.org/jdk/pull/20072#issuecomment-2222804204 From stuefe at openjdk.org Thu Jul 11 13:02:56 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 11 Jul 2024 13:02:56 GMT Subject: RFR: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 [v2] In-Reply-To: References: Message-ID: <2yrniNflturFOvkIjWdvHwOtnjs_3qNEisXW9x-lZDU=.1daf7706-5677-4a48-be66-e090d62b391c@github.com> On Thu, 11 Jul 2024 12:30:29 GMT, Matthias Baesken wrote: >> Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : >> serviceability/dcmd/vm/SystemDumpMapTest.java >> >> Missing patterns in dump: >> 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] >> test SystemDumpMapTest.jmx(): failure >> java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns >> at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) >> at SystemDumpMapTest.run(SystemDumpMapTest.java:106) >> at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) >> at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) >> at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) >> at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) >> at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) >> at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) >> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) >> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) >> .... >> >> Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. >> So better avoid the check because it is based on false assumptions. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > test for heap segment Thanks Matthias. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20072#pullrequestreview-2171829773 From coleenp at openjdk.org Thu Jul 11 13:11:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Jul 2024 13:11:04 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/arguments.cpp line 1830: >> >>> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); >>> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); >>> 1830: } >> >> Maybe we want this to have the opposite sense - turn off UseObjectMonitorTable if not LM_LIGHTWEIGHT? > > Maybe. It boils down to what to do when the JVM receives `-XX:LockingMode={LM_LEGACY,LM_MONITOR} -XX:+UseObjectMonitorTable` > The options I see are > 1. Select `LockingMode=LM_LIGHTWEIGHT` > 2. Select `UseObjectMonitorTable=false` > 3. Do not start the VM > > Between 1. and 2. it is impossible to know what the real intentions were. But with being a newer `-XX:+UseObjectMonitorTable` it somehow seems more likely. > > Option 3. is probably the sensible solution, but it is hard to determine. We tend to not close the VM because of incompatible options, rather fix them. But I believe there are precedence for both. If we do this however we will have to figure out all the interactions with our testing framework. And probably add some safeguards. UseObjectMonitorTable is a Diagnostic option and LockingMode is (Deprecated) but a full-fledged product option, so I think the product option should override. So I pick 2. They might have changed to Legacy to compare performance or something like that, and missed that the table is only for lightweight locking when switching the command line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673989707 From coleenp at openjdk.org Thu Jul 11 13:13:57 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Jul 2024 13:13:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: <7_99_ouQ3MAtPFgIQzG01AlOOgFLGPrK1h1LMzzhK60=.0578b32c-8f8b-460c-a5c1-e5686369aba5@github.com> On Wed, 10 Jul 2024 09:41:37 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763: >> >>> 761: assert(mark.has_monitor(), "must be"); >>> 762: // The monitor exists >>> 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current, object, mark); >> >> This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? Or we got here because BasicLock.metadata was not the ObjectMonitor? > >> This looks in the table for the monitor in UseObjectMonitorTable, but could it first check the BasicLock? > > We could. > >> Or we got here because BasicLock.metadata was not the ObjectMonitor? > > That is one reason we got here. We also get here from C1/interpreter as well as if there are other threads on the entry queues. > > I think there was an assumption that it would not be that crucial in those cases. > > One off the reasons we do not read the `BasicLock` cache from the runtime is that we are not as careful with keeping the `BasicLock` initialised on platforms without `UseObjectMonitorTable`. The idea was that as long as they call into the VM, we do not need to keep it invariant. > > But this made me realise `BasicLock::print_on` will be broken on non x86/aarch64 platforms if running with `UseObjectMonitorTable`. > > Rather then fix all platforms I will condition BasicLock::object_monitor_cache to return nullptr on not supported platforms. > > Could add this then. Should probably add an overload to `ObjectSynchronizer::read_monitor` which takes the lock and push i all the way here. I think I'd prefer not another overloading of read_monitor. It's kind of confusing as is. This is okay and we'll see if there's any performance benefit to checking BasicLock instead later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1673993770 From cjplummer at openjdk.org Thu Jul 11 14:13:07 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 14:13:07 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes wrote: >> Which logging should be removed? Alex suggest the logging between breakpoints 2 and 3, but even that is not enough. There is logging after breakpoint 3, and that happens before the vm.resume() is done. I'm not saying this can't be done right, but I think pruning out logging like this in order to fix the problem not only removes some valuable logging from the test, but still leaves us open to this type of issue. >> >> I think the safer thing to do is to make sure mainThread is no longer logging (or will attempt to log) when the vmsuspend is done. This could be done by pruning some of its logging, but that has the same negatives as removing some thread2 logging. My sleep suggestion is by far the simplest. The "purist" fix would probably be the checkpoint approach (don't do the vm.suspend until mainThread has reached a stable point). That ended up getting a bit uglier than I had hoped, but I can finish up the work so you can have a look at it if you'd like. > > Sorry I'm unclear on the different threads involved here. IIUC the vm.suspend comes from the debugger, and the mainthread and thread-2 are both threads in the debuggee, being suspended at different times? Yes. thread2 is suspended via breakpoint (multiple times). mainThread is suspended by the one place in the test that does a vm.suspend(), which is near the end of the test. This is the problematic suspend because sometimes it is done while mainThread is in the middle of a println. A bit later thread2 is resumed and ends up blocking on a println due to mainThread holding the needed lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1674085843 From kevinw at openjdk.org Thu Jul 11 15:03:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 15:03:25 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name Message-ID: Follow-on from JDK-8207908. Two tests are broken by that change: sun/management/jmxremote/startstop/JMXStartStopTest.java sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java These are additional tests which use jcmd and an application name pattern to find a process. They should use the PID to avoid finding a process from some other concurrent test invocation. So it's good to have the same kind of change applied here too. ------------- Commit messages: - 8336257: Additional tests in jmxremote/startstop to match on PID not app name Changes: https://git.openjdk.org/jdk/pull/20138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336257 Stats: 7 lines in 2 files changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20138/head:pull/20138 PR: https://git.openjdk.org/jdk/pull/20138 From cjplummer at openjdk.org Thu Jul 11 15:25:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 15:25:55 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote: > Follow-on from JDK-8207908. > > Two tests are broken by that change: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java > > These are additional tests which use jcmd and an application name pattern to find a process. > They should use the PID to avoid finding a process from some other concurrent test invocation. > So it's good to have the same kind of change applied here too. test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java line 351: > 349: pid = p.pid(); > 350: jcmd = new ManagementAgentJcmd(p, verbose); > 351: I don't think you want a blank line here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20138#discussion_r1674217138 From kevinw at openjdk.org Thu Jul 11 15:38:29 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 15:38:29 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: > Follow-on from JDK-8207908. > > Two tests are broken by that change: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java > > These are additional tests which use jcmd and an application name pattern to find a process. > They should use the PID to avoid finding a process from some other concurrent test invocation. > So it's good to have the same kind of change applied here too. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20138/files - new: https://git.openjdk.org/jdk/pull/20138/files/caaf27a0..9c025ea7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20138&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20138&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20138/head:pull/20138 PR: https://git.openjdk.org/jdk/pull/20138 From kevinw at openjdk.org Thu Jul 11 15:38:30 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 15:38:30 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: <08TPoYWhaKMcUaJP6b1iE1JTfTBVokmnCHmestvg1lg=.14f71877-00d6-41b5-9e47-3aa92903c760@github.com> On Thu, 11 Jul 2024 15:22:54 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> line > > test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java line 351: > >> 349: pid = p.pid(); >> 350: jcmd = new ManagementAgentJcmd(p, verbose); >> 351: > > I don't think you want a blank line here. I don't mind the additional space, but ok have removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20138#discussion_r1674239544 From cjplummer at openjdk.org Thu Jul 11 16:01:27 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 16:01:27 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v2] In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: - New solution. Use a sync point to force debugger to wait until mainThread is no longer doing a println() - Make printThreadsInfo() public so tests can call it. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20088/files - new: https://git.openjdk.org/jdk/pull/20088/files/b70bcd19..a5d0abc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=00-01 Stats: 40 lines in 3 files changed: 26 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20088/head:pull/20088 PR: https://git.openjdk.org/jdk/pull/20088 From cjplummer at openjdk.org Thu Jul 11 16:01:27 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 16:01:27 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v2] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Thu, 11 Jul 2024 14:09:57 GMT, Chris Plummer wrote: >> Sorry I'm unclear on the different threads involved here. IIUC the vm.suspend comes from the debugger, and the mainthread and thread-2 are both threads in the debuggee, being suspended at different times? > > Yes. thread2 is suspended via breakpoint (multiple times). mainThread is suspended by the one place in the test that does a vm.suspend(), which is near the end of the test. This is the problematic suspend because sometimes it is done while mainThread is in the middle of a println. A bit later thread2 is resumed and ends up blocking on a println due to mainThread holding the needed lock. I've updated the implementation so now it does a sync point after mainThread is done with printlns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1674279814 From cjplummer at openjdk.org Thu Jul 11 16:01:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 16:01:57 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote: >> Follow-on from JDK-8207908. >> >> Two tests are broken by that change: >> sun/management/jmxremote/startstop/JMXStartStopTest.java >> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java >> >> These are additional tests which use jcmd and an application name pattern to find a process. >> They should use the PID to avoid finding a process from some other concurrent test invocation. >> So it's good to have the same kind of change applied here too. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > line Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20138#pullrequestreview-2172367956 From alanb at openjdk.org Thu Jul 11 16:48:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Jul 2024 16:48:56 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: <9So0cdd_2xrkZY99DfBsjDNj4d6PxVpjd1XfNzrKo98=.ed13266c-fc17-4d93-bf17-c6ff1a46506c@github.com> On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote: >> Follow-on from JDK-8207908. >> >> Two tests are broken by that change: >> sun/management/jmxremote/startstop/JMXStartStopTest.java >> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java >> >> These are additional tests which use jcmd and an application name pattern to find a process. >> They should use the PID to avoid finding a process from some other concurrent test invocation. >> So it's good to have the same kind of change applied here too. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > line Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20138#pullrequestreview-2172467658 From gli at openjdk.org Thu Jul 11 17:38:15 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 11 Jul 2024 17:38:15 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 20:29:37 GMT, Albert Mingkun Yang wrote: >> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. >> >> The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. >> >> Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. > > Albert Mingkun Yang 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 > - Merge branch 'master' into pgc-vm-operation > - pgc-vm-operation Nice refactor. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 434: > 432: void ParallelScavengeHeap::do_full_collection_no_gc_locker(bool clear_all_soft_refs) { > 433: bool maximum_compaction = clear_all_soft_refs; > 434: PSParallelCompact::invoke(maximum_compaction); The parameter `maximum_heap_compaction` of the method `PSParallelCompact::invoke` was changed to `clear_all_soft_refs` in [JDK-8334445](https://git.openjdk.org/jdk/pull/19763), so the variable `maximum_compaction` seems not necessary here. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 443: > 441: if (result == nullptr && !is_tlab) { > 442: // auto expand inside > 443: result = old_gen()->allocate(size); If we expand the generation in the method `PSOldGen::allocate`. I think it is good to rename the method to `expand_and_allocate` (just like `TenuredGeneration::expand_and_allocate` in SerialGC). It is better to be polished at a followup issue. src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 446: > 444: } > 445: return result; // Could be null if we are out of space. > 446: } I notice the method `PSOldGen::allocate` can expand the size of the old gen, but the method `PSYoungGen::allocate` can't expand the size of the young gen. It is similar to a bug [1] in Serial. Fortunately, the size of the young generation can be resized during Parallel GC if the option `UseAdaptiveSizePolicy` is `true`. When the `UseAdaptiveSizePolicy` is set to `false` manually by the user, I suspect it is a bug in Parallel because of the unexpanded young generation size. [1] https://bugs.openjdk.org/browse/JDK-8333386 src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 478: > 476: > 477: const bool clear_all_soft_refs = true; > 478: do_full_collection_no_gc_locker(clear_all_soft_refs); If the young collection succeeded in method `collect_at_safepoint`. The normal full collection won't run in `collect_at_safepoint`. If the successful young collection didn't release any memory (or only released little memory but not enough for allocation), the allocation in line 462 will fail too. Then a full collection with maximum compaction will be run. It is strange. In my opinion, I think the steps look like below: 1. allocation 2. young collection 3. allocation 4. normal full collection 5. allocation 6. maximum full collection 7. allocation 8. OOM But in current patch, the step 4-5 may be skipped. src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 114: > 112: > 113: // Perform a full collection > 114: void do_full_collection(bool clear_all_soft_refs) override; The comment seems redundant. src/hotspot/share/gc/parallel/psScavenge.cpp line 232: > 230: // Note that this method should only be called from the vm_thread while > 231: // at a safepoint! > 232: bool PSScavenge::invoke() { Nice removal. It is strange to run a full collection in `PSScavenge` before. ------------- Changes requested by gli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20077#pullrequestreview-2172099153 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674132961 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674390370 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674247874 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674379967 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674344233 PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674384804 From gli at openjdk.org Thu Jul 11 17:38:15 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 11 Jul 2024 17:38:15 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 14:39:47 GMT, Guoxiong Li wrote: >> Albert Mingkun Yang 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 >> - Merge branch 'master' into pgc-vm-operation >> - pgc-vm-operation > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 434: > >> 432: void ParallelScavengeHeap::do_full_collection_no_gc_locker(bool clear_all_soft_refs) { >> 433: bool maximum_compaction = clear_all_soft_refs; >> 434: PSParallelCompact::invoke(maximum_compaction); > > The parameter `maximum_heap_compaction` of the method `PSParallelCompact::invoke` was changed to `clear_all_soft_refs` in [JDK-8334445](https://git.openjdk.org/jdk/pull/19763), so the variable `maximum_compaction` seems not necessary here. If the variable `maximum_compaction` is removed, it may be better to use `PSParallelCompact::invoke` directly and remove the method `do_full_collection_no_gc_locker` (just like using `PSScavenge::invoke` directly). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674260428 From ayang at openjdk.org Thu Jul 11 18:06:34 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Jul 2024 18:06:34 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v4] In-Reply-To: References: Message-ID: > Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. > > The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. > > Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into pgc-vm-operation - review - review - Merge branch 'master' into pgc-vm-operation - pgc-vm-operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20077/files - new: https://git.openjdk.org/jdk/pull/20077/files/1d10dd5b..974b6b08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20077&range=02-03 Stats: 1640 lines in 65 files changed: 1034 ins; 342 del; 264 mod Patch: https://git.openjdk.org/jdk/pull/20077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20077/head:pull/20077 PR: https://git.openjdk.org/jdk/pull/20077 From ayang at openjdk.org Thu Jul 11 18:14:37 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Jul 2024 18:14:37 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:10:58 GMT, Guoxiong Li wrote: > If the successful young collection didn't release any memory (or only released little memory but not enough for allocation), A successful young-gc often leave young-gen completely empty. Otherwise, max-compaction full-gc should be run -- there is little benefit of running non-max-compaction full-gc if old-gen is too packed to hold all young-gen objs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674452022 From amenkov at openjdk.org Thu Jul 11 18:44:09 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 11 Jul 2024 18:44:09 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v2] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 16:01:27 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: > > - New solution. Use a sync point to force debugger to wait until mainThread is no longer doing a println() > - Make printThreadsInfo() public so tests can call it. I'm ok with the new solution. Need to update copyright year in resume001a.java and fix whitespace issue in resume001.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2223649197 From amenkov at openjdk.org Thu Jul 11 18:44:09 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 11 Jul 2024 18:44:09 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v2] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <9QFY6xK5EoVoXp6xlZI0GLYYVWxZpnyDRAWgqHbb9EE=.9b500b5e-e389-44f1-ac6d-46526395d5ba@github.com> Message-ID: On Thu, 11 Jul 2024 15:58:13 GMT, Chris Plummer wrote: >> Yes. thread2 is suspended via breakpoint (multiple times). mainThread is suspended by the one place in the test that does a vm.suspend(), which is near the end of the test. This is the problematic suspend because sometimes it is done while mainThread is in the middle of a println. A bit later thread2 is resumed and ends up blocking on a println due to mainThread holding the needed lock. > > I've updated the implementation so now it does a sync point after mainThread is done with printlns. > Which logging should be removed? Alex suggest the logging between breakpoints 2 and 3, but even that is not enough. There is logging after breakpoint 3, and that happens before the vm.resume() is done. After breakpoint 3 debugger calls thread2.resume() and vm.resume(), so there is no issue there (all threads are resumed). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1674512891 From amenkov at openjdk.org Thu Jul 11 18:46:59 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 11 Jul 2024 18:46:59 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote: >> Follow-on from JDK-8207908. >> >> Two tests are broken by that change: >> sun/management/jmxremote/startstop/JMXStartStopTest.java >> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java >> >> These are additional tests which use jcmd and an application name pattern to find a process. >> They should use the PID to avoid finding a process from some other concurrent test invocation. >> So it's good to have the same kind of change applied here too. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > line Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20138#pullrequestreview-2172761638 From dcubed at openjdk.org Thu Jul 11 20:34:58 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 11 Jul 2024 20:34:58 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: <5z16povNL44HwKLPQjIm-ypQm4dSD4TWCU8iguwZP6M=.2dcaab38-badb-42d6-8858-20e833a6e0fd@github.com> On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote: >> Follow-on from JDK-8207908. >> >> Two tests are broken by that change: >> sun/management/jmxremote/startstop/JMXStartStopTest.java >> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java >> >> These are additional tests which use jcmd and an application name pattern to find a process. >> They should use the PID to avoid finding a process from some other concurrent test invocation. >> So it's good to have the same kind of change applied here too. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > line The fix looks good to me. I presume it has been tested with a Mach5 Tier3 job set. @kevinjwalls - When do you expect to integrate this fix? It looks like we're seeing 34 failures per Tier3 job set due to this issue. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20138#pullrequestreview-2172977359 PR Comment: https://git.openjdk.org/jdk/pull/20138#issuecomment-2223872373 From kevinw at openjdk.org Thu Jul 11 20:47:56 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 20:47:56 GMT Subject: Integrated: 8336257: Additional tests in jmxremote/startstop to match on PID not app name In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote: > Follow-on from JDK-8207908. > > Two tests are broken by that change: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java > > These are additional tests which use jcmd and an application name pattern to find a process. > They should use the PID to avoid finding a process from some other concurrent test invocation. > So it's good to have the same kind of change applied here too. This pull request has now been integrated. Changeset: 687601eb Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/687601ebcaedf133fd4d5cecc42c5aadf9c73f3c Stats: 6 lines in 2 files changed: 2 ins; 1 del; 3 mod 8336257: Additional tests in jmxremote/startstop to match on PID not app name Reviewed-by: cjplummer, alanb, amenkov, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/20138 From kevinw at openjdk.org Thu Jul 11 20:47:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 20:47:55 GMT Subject: RFR: 8336257: Additional tests in jmxremote/startstop to match on PID not app name [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote: >> Follow-on from JDK-8207908. >> >> Two tests are broken by that change: >> sun/management/jmxremote/startstop/JMXStartStopTest.java >> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java >> >> These are additional tests which use jcmd and an application name pattern to find a process. >> They should use the PID to avoid finding a process from some other concurrent test invocation. >> So it's good to have the same kind of change applied here too. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > line Yes, tier3 test job came back ok, will integrate now. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20138#issuecomment-2223909205 From kevinw at openjdk.org Thu Jul 11 21:38:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 21:38:25 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Message-ID: Short version: Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" Make additional typo fixes and tidyups while here, it's just shocking. TestDescription.java contains the test definition, so the "requires" goes there, with a comment. Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. ------------- Commit messages: - update - 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Changes: https://git.openjdk.org/jdk/pull/20146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332551 Stats: 76 lines in 2 files changed: 34 ins; 1 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/20146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20146/head:pull/20146 PR: https://git.openjdk.org/jdk/pull/20146 From kevinw at openjdk.org Thu Jul 11 21:38:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Jul 2024 21:38:25 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out In-Reply-To: References: Message-ID: <-XpY8x_pXUa7GpCDNVGLMyBMRf9F0Q6WeeqDirvwDNY=.60430ec7-49d3-4c97-b9e4-0b197dd7cbda@github.com> On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote: > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. Longer version: When the test fails, it is monitoring the old gen of either Parallel, Serial, or ZGC (Generational) collector, and is running with -Xcomp. In the HotSpot Event log of the failure, Java heap is completely stable, but usage may drop off in the last collection. The "eatMemory" call is not working? More likely it has done its work, and the -Xcomp throws off the timing, such that no Notification ever appears. The call to retrieve the data from the queue sleeps forever, until the test harness times it out. We could play games with eatMemory: have it work harder, consume more memory, work for longer, pause before starting... But this is a chasing game with goals that are hard to monitor and may well need future changes. Also tried a version that tolerates the failure: just don't fail if the Notification data is not available. This works, and it's fine if it skips one in some large number of runs (not that I can reproduce that), but the problem is there's no way of finding out if it starts skipping it all the time. Overall it seems better to not run this test with -Xcomp. I'm keeping the reading of the queue changed to poll with a timeout, which was used to test tolerating the Notification never arriving. It keeps down the max time needed if it fails. The Notification usually happens immediately, and being stuck in a long delay is unnecessary. Without Xcomp, the test should take a few seconds overall, so at a minute without a Notification it should give up and fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20146#issuecomment-2223952615 From cjplummer at openjdk.org Thu Jul 11 22:36:05 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Jul 2024 22:36:05 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix copyright and jcheck error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20088/files - new: https://git.openjdk.org/jdk/pull/20088/files/a5d0abc1..3c9b88d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20088/head:pull/20088 PR: https://git.openjdk.org/jdk/pull/20088 From gli at openjdk.org Fri Jul 12 01:18:00 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 12 Jul 2024 01:18:00 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: <2u2YExr_N6N4lae-i_FV8JVbEOT6cYzOHAftkb2BOmY=.f87ac878-9d9a-45c0-a20d-a5ffb1cabcad@github.com> On Thu, 11 Jul 2024 18:09:24 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 478: >> >>> 476: >>> 477: const bool clear_all_soft_refs = true; >>> 478: do_full_collection_no_gc_locker(clear_all_soft_refs); >> >> If the young collection succeeded in method `collect_at_safepoint`. The normal full collection won't run in `collect_at_safepoint`. If the successful young collection didn't release any memory (or only released little memory but not enough for allocation), the allocation in line 462 will fail too. Then a full collection with maximum compaction will be run. It is strange. In my opinion, I think the steps look like below: >> >> 1. allocation >> 2. young collection >> 3. allocation >> 4. normal full collection >> 5. allocation >> 6. maximum full collection >> 7. allocation >> 8. OOM >> >> But in current patch, the step 4-5 may be skipped. > >> If the successful young collection didn't release any memory (or only released little memory but not enough for allocation), > > A successful young-gc often leave young-gen completely empty. Otherwise, max-compaction full-gc should be run -- there is little benefit of running non-max-compaction full-gc if old-gen is too packed to hold all young-gen objs. Thanks for your explanation. I am OK with the current solution now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674923459 From gli at openjdk.org Fri Jul 12 01:24:58 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 12 Jul 2024 01:24:58 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: References: Message-ID: <0bOEaMQ75JB0T22pbSsMEP1UV7lh1pUHoGjgTkold-w=.bfdbb2f7-010d-4d24-ab79-7fc40aadc929@github.com> On Thu, 11 Jul 2024 15:40:01 GMT, Guoxiong Li wrote: >> Albert Mingkun Yang 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 >> - Merge branch 'master' into pgc-vm-operation >> - pgc-vm-operation > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 446: > >> 444: } >> 445: return result; // Could be null if we are out of space. >> 446: } > > I notice the method `PSOldGen::allocate` can expand the size of the old gen, but the method `PSYoungGen::allocate` can't expand the size of the young gen. It is similar to a bug [1] in Serial. Fortunately, the size of the young generation can be resized during Parallel GC if the option `UseAdaptiveSizePolicy` is `true`. When the `UseAdaptiveSizePolicy` is set to `false` manually by the user, I suspect it is a bug in Parallel because of the unexpanded young generation size. > > [1] https://bugs.openjdk.org/browse/JDK-8333386 @albertnetymk Do you think whether we need to expand young generation during allocation (both Serial and Parallel)? In Serial, `UseAdaptiveSizePolicy` is not used, so it is indeed a bug in Serial (the young generation can't be resized and is always the initial size). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1674933630 From sspitsyn at openjdk.org Fri Jul 12 02:25:49 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 02:25:49 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote: > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java line 171: > 169: if (!messageReceived) { > 170: throw new TestFailure("No Notification received."); > 171: } else { Nit: The "else" is not really needed. Removing it will simplify the change diff. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20146#discussion_r1675021648 From amenkov at openjdk.org Fri Jul 12 02:29:59 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 02:29:59 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2173556478 From sspitsyn at openjdk.org Fri Jul 12 02:31:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 02:31:57 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out In-Reply-To: References: Message-ID: <6I-Tv-ntI2nFy_vlobVY1IYMTHX4WJG2dFHorVeH0XA=.fe1d399e-8107-4ba6-856f-cab29ca64b6a@github.com> On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote: > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. Looks good. Posted a couple of nits. test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java line 180: > 178: > 179: log.display("poolObjectName : " + poolObjectName + > 180: " resultObjectName : " + resultObjectName); Nit: It'd be nice to fix the incorrect indent (it was in original code). ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20146#pullrequestreview-2173555008 PR Review Comment: https://git.openjdk.org/jdk/pull/20146#discussion_r1675023040 From dholmes at openjdk.org Fri Jul 12 02:47:57 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Jul 2024 02:47:57 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error FWIW I think the explicit sync with the mainthread seems reasonable too. test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java line 382: > 380: if (expresult != returnCode0) { > 381: vm.resume(); > 382: vm.resume(); // for case error when both VirtualMachine and the thread2 were suspended Pre-existing but I don't understand the comment. Why would you need 2 `vm.resume()` here? If `thread2` was suspended directly don't you need a `thread2.resume()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2173568846 PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1675036756 From sspitsyn at openjdk.org Fri Jul 12 03:06:50 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 03:06:50 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 23:08:37 GMT, David Holmes wrote: > My concern is that the logic was wrong and so you fixed it, but this then screams out for a test that would have detected the error, but you can't write a test because the line can never be empty, so that becomes an invariant rather than a runtime check. Do I understand this right that the suggestion is to add an explicit runtime check for non-emptiness and report an error if an empty line has been discovered? If so, then the `is_empty()`check can be removed from the `CmdLine::is_executable()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2224336709 From sspitsyn at openjdk.org Fri Jul 12 03:23:51 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 03:23:51 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error I agree with Chris that this test is over-complicated. The introduction of the explicit sync makes it easier to understand. I've got also confused by the two pre-existed sub-sequential `vm.resume()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2224350876 From syan at openjdk.org Fri Jul 12 03:29:06 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 03:29:06 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 Message-ID: Hi all, Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. ------------- Commit messages: - 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 Changes: https://git.openjdk.org/jdk/pull/20151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336284 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20151/head:pull/20151 PR: https://git.openjdk.org/jdk/pull/20151 From sspitsyn at openjdk.org Fri Jul 12 03:32:51 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 03:32:51 GMT Subject: RFR: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote: > The test test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java should be removed. > > This test was added when 6984520 was fixed in 6u25. It has been problemlisted since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it just wanted something "RMI" to connect with). > > Looking at the change it tested, the code is no longer the same, and is no longer at risk of this NPE. > > The original NPE fix was to check that jxmServerviceURL was not null before calling methods on it, but the current RMIConnector.java does not make those same calls. > > It is best to remove the test and its problemlist entry. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20054#pullrequestreview-2173628927 From dholmes at openjdk.org Fri Jul 12 03:48:50 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Jul 2024 03:48:50 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:04:06 GMT, Serguei Spitsyn wrote: > Do I understand this right that the suggestion is to add an explicit runtime check for non-emptiness and report an error if an empty line has been discovered? If so, then the `is_empty()`check can be removed from the `CmdLine::is_executable()`. Basically yes. If the line can never be empty then assert that is the case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2224379855 From cjplummer at openjdk.org Fri Jul 12 04:10:53 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 04:10:53 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> Message-ID: On Fri, 12 Jul 2024 02:44:28 GMT, David Holmes wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright and jcheck error > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java line 382: > >> 380: if (expresult != returnCode0) { >> 381: vm.resume(); >> 382: vm.resume(); // for case error when both VirtualMachine and the thread2 were suspended > > Pre-existing but I don't understand the comment. Why would you need 2 `vm.resume()` here? If `thread2` was suspended directly don't you need a `thread2.resume()`? First just to clarify a general JDI feature about thread suspending and resuming. You can undo a ThreadReference.suspend() or a thread suspended as the result of an event by dong a vm.resume(). This is documented in the JDI API spec, which talks about suspendCounts and how various APIs and event delivery affect them. I was tempted to clean up these vm.resume() calls but opted not to. The point being made in the comment is that worse case thread2 was suspended by a breakpoint or thread2.suspend() and all threads were suspended by a vm.resume() (meaning thread2 could have a suspendCount of 2). Two vm.resumes() take are done to make sure thread2 gets resumed under this situation. However, one of the vm.resume calls could instead be a thread2.resume(). Doing two vm.resume() calls was probably just laziness by the original authors. It works though. However, by my accounting at any failure point thread2 never has a suspendCount > 1, so really just one vm.resume() would be enough. The original code did these two vm.resume() calls unconditionally, but they are not needed if there was no error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1675243246 From cjplummer at openjdk.org Fri Jul 12 04:24:50 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 04:24:50 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/0db4f21ce22a5700d6d2a29efc1289c8231266bb/hotspot/src/share/vm/runtime/vframe.cpp#L185 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. Marked as reviewed by cjplummer (Reviewer). I just want to clarify that the "" message is coming from the SA JavaVFrame.java file, not the vframe.cpp code you mention in the PR description. ------------- PR Review: https://git.openjdk.org/jdk/pull/20151#pullrequestreview-2173821723 PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2224526136 From aboldtch at openjdk.org Fri Jul 12 05:57:30 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 05:57:30 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update arguments.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/a207544b..15997bc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From mbaesken at openjdk.org Fri Jul 12 05:59:58 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 12 Jul 2024 05:59:58 GMT Subject: Integrated: 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 11:06:45 GMT, Matthias Baesken wrote: > Unfortunately those 2 tests fail now on Linux Alpine (x86_64) : > serviceability/dcmd/vm/SystemDumpMapTest.java > > Missing patterns in dump: > 0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[vdso\] > test SystemDumpMapTest.jmx(): failure > java.lang.RuntimeException: java.lang.RuntimeException: Missing patterns > at SystemDumpMapTest.run_test(SystemDumpMapTest.java:100) > at SystemDumpMapTest.run(SystemDumpMapTest.java:106) > at SystemDumpMapTest.jmx(SystemDumpMapTest.java:112) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > .... > > Reason is that the vdso lib is not there on all Linux flavors; e.g. we do not seem to have it on our Alpine Linux test system. > So better avoid the check because it is based on false assumptions. This pull request has now been integrated. Changeset: c703d290 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c703d290425f85a06e61d72c9672ac2adac92db9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475 Reviewed-by: stuefe, lucy ------------- PR: https://git.openjdk.org/jdk/pull/20072 From sspitsyn at openjdk.org Fri Jul 12 06:25:52 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 06:25:52 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2173967874 From syan at openjdk.org Fri Jul 12 06:39:51 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 06:39:51 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. > I just want to clarify that the "" message is coming from the SA JavaVFrame.java file, not the vframe.cpp code you mention in the PR description. Thanks for the correction. The PR description has been updated. Fix the testcase bug, I think it's not need the 2rd reviewer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2224890815 PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2224894273 From duke at openjdk.org Fri Jul 12 06:39:51 2024 From: duke at openjdk.org (duke) Date: Fri, 12 Jul 2024 06:39:51 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. @sendaoYan Your change (at version 5925efa3c34a9e63ce7b62d7244afc141c582fed) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2224899546 From jwaters at openjdk.org Fri Jul 12 06:40:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 12 Jul 2024 06:40:20 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK Message-ID: snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the null terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) ------------- Commit messages: - Obliterate most references to _snprintf in the Windows JDK Changes: https://git.openjdk.org/jdk/pull/20153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336289 Stats: 35 lines in 12 files changed: 0 ins; 16 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From amenkov at openjdk.org Fri Jul 12 08:04:53 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 08:04:53 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> Message-ID: On Fri, 12 Jul 2024 04:08:25 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java line 382: >> >>> 380: if (expresult != returnCode0) { >>> 381: vm.resume(); >>> 382: vm.resume(); // for case error when both VirtualMachine and the thread2 were suspended >> >> Pre-existing but I don't understand the comment. Why would you need 2 `vm.resume()` here? If `thread2` was suspended directly don't you need a `thread2.resume()`? > > First just to clarify a general JDI feature about thread suspending and resuming. You can undo a ThreadReference.suspend() or a thread suspended as the result of an event by dong a vm.resume(). This is documented in the JDI API spec, which talks about suspendCounts and how various APIs and event delivery affect them. > > I was tempted to clean up these vm.resume() calls but opted not to. The point being made in the comment is that worse case thread2 was suspended by a breakpoint or thread2.suspend() and all threads were suspended by a vm.resume() (meaning thread2 could have a suspendCount of 2). Two vm.resumes() take are done to make sure thread2 gets resumed under this situation. However, one of the vm.resume calls could instead be a thread2.resume(). Doing two vm.resume() calls was probably just laziness by the original authors. It works though. > > However, by my accounting at any failure point thread2 never has a suspendCount > 1, so really just one vm.resume() would be enough. > > The original code did these two vm.resume() calls unconditionally, but they are not needed if there was no error. The original code had 2 vm.resume() - one on them to match vm.suspend() and 2nd one to allow debugee to continue on error. Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2 conditional (on error). Theoretically we can get an error when both vm and thread2 are suspended, so 2 vm.resume() looks reasonable. Anyway resume() is a nop if the thread is not suspended ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1675474511 From amenkov at openjdk.org Fri Jul 12 08:14:50 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 08:14:50 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: <59t3In5UuAmYbPghaFDXoJncbics4w3hc6KMiLZPpuo=.e7fc4ce3-f805-4960-b838-fe84b2176da9@github.com> On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20151#pullrequestreview-2174140888 From syan at openjdk.org Fri Jul 12 08:17:56 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 08:17:56 GMT Subject: Integrated: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. This pull request has now been integrated. Changeset: 1fe3ada0 Author: SendaoYan Committer: Alex Menkov URL: https://git.openjdk.org/jdk/commit/1fe3ada001e188754df5de00bf6804f028ad274b Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/20151 From kevinw at openjdk.org Fri Jul 12 08:21:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 08:21:54 GMT Subject: RFR: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote: > The test test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java should be removed. > > This test was added when 6984520 was fixed in 6u25. It has been problemlisted since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it just wanted something "RMI" to connect with). > > Looking at the change it tested, the code is no longer the same, and is no longer at risk of this NPE. > > The original NPE fix was to check that jxmServerviceURL was not null before calling methods on it, but the current RMIConnector.java does not make those same calls. > > It is best to remove the test and its problemlist entry. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20054#issuecomment-2225065743 From kevinw at openjdk.org Fri Jul 12 08:21:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 08:21:54 GMT Subject: Integrated: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote: > The test test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java should be removed. > > This test was added when 6984520 was fixed in 6u25. It has been problemlisted since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it just wanted something "RMI" to connect with). > > Looking at the change it tested, the code is no longer the same, and is no longer at risk of this NPE. > > The original NPE fix was to check that jxmServerviceURL was not null before calling methods on it, but the current RMIConnector.java does not make those same calls. > > It is best to remove the test and its problemlist entry. This pull request has now been integrated. Changeset: f677b90e Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/f677b90eb93026d3fdfd4ae19d48415a7d8318e8 Stats: 79 lines in 2 files changed: 0 ins; 79 del; 0 mod 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123) Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/20054 From syan at openjdk.org Fri Jul 12 08:30:52 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 08:30:52 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: <7HLFSo1GrQiFd4nl7-2zNhDlXbXO7UWkfctJixQy7YQ=.350fc25e-3399-4efa-a79e-ec4709c49899@github.com> On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. Thanks for the sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2225079469 From amenkov at openjdk.org Fri Jul 12 08:30:52 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 08:30:52 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: <2rqwT4EO75vR4y3u-W5eRndUqg8JFhuwjaS8kkoqs28=.7bdb7a7e-b252-49c7-85f4-f41dedbbb3e0@github.com> On Fri, 12 Jul 2024 06:34:57 GMT, SendaoYan wrote: > Fix the testcase bug, I think it's not need the 2rd reviewer. My bad for hasty sponsorship. General rules are applied to test fixes - 2 reviewers and at least 24 hours for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2225082014 From syan at openjdk.org Fri Jul 12 08:38:00 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 12 Jul 2024 08:38:00 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: <2rqwT4EO75vR4y3u-W5eRndUqg8JFhuwjaS8kkoqs28=.7bdb7a7e-b252-49c7-85f4-f41dedbbb3e0@github.com> References: <2rqwT4EO75vR4y3u-W5eRndUqg8JFhuwjaS8kkoqs28=.7bdb7a7e-b252-49c7-85f4-f41dedbbb3e0@github.com> Message-ID: <_ylGYLa1wzKKboUfNeg576sN_HKLX6BFy-FljH1dMsg=.36033afa-c347-49bc-b085-81aef94abcab@github.com> On Fri, 12 Jul 2024 08:27:47 GMT, Alex Menkov wrote: > > Fix the testcase bug, I think it's not need the 2rd reviewer. > > My bad for hasty sponsorship. General rules are applied to test fixes - 2 reviewers and at least 24 hours for review. Sorry for hasty integrate, I will pay attention next time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2225094443 From alanb at openjdk.org Fri Jul 12 09:11:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Jul 2024 09:11:58 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Wed, 10 Jul 2024 16:56:37 GMT, Volker Simonis wrote: >> src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java line 179: >> >>> 177: * This means that a {@link LinkageError} triggered during transformation of >>> 178: * {@code C} in a class {@code D} not directly related to {@code C} can repeatedly >>> 179: * occur later in arbitrary user code which uses {@code D}. >> >> This paragraph looks okay but I can't help thinking we should have something in normative text to reference that specifies the reentrancy behavior. Maybe I missed it but I thought we have something in the API docs on this. > > I haven't found anything either. The only specification-relevant mentioning of the issue I found is in the [JVMTI Specification](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) referenced at the beginning of the PR: > >> Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes. > > The example that follows describes an infinite recursion when instrumenting the the `j.l.Object()` constructor. > > I think the exact reentrancy behavior isn't specified anywhere. Not even the exact that should be thrown in such a case is specified (see [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165) for a discussion of different scenarios). > > I think the real problem is that the JVMS predates the JVMTI specification and the interaction between instrumentation and class loading isn't clearly defined. I think it might even be possible to treat class loading errors during transformation differently, such that they will not lead to a permanent resolution error for the corresponding constant pool entries. I know that this will violate the current section ? 5.4.3 Resolution (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3) of the JVM specification which mandates that "if an attempt by the Java Virtual Machine to resolve a symbolic reference fails because an error is thrown that is an instance of LinkageError (or a subclass), then subsequent attempts to resolve the reference always fail with the same error that was thrown as a result of the initial resolution attempt". But as I wrote, that predates JVMTI and when JVMTI was added, we missed the opportunity to specify its exact impact on class loading and resolution. > > But all this is a much bigger discussion. Maybe we should open another issue for it? I've created [JDK-8336296)](https://bugs.openjdk.org/browse/JDK-8336296) for the spec issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20011#discussion_r1675558673 From kevinw at openjdk.org Fri Jul 12 09:16:05 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 09:16:05 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v2] In-Reply-To: References: Message-ID: <5w-lZYTr6ZVThJZFscOqVevqSvwvnMXcIB49TuuZIUM=.2b93bc7b-0d7c-4ffd-9811-2846f0502999@github.com> > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20146/files - new: https://git.openjdk.org/jdk/pull/20146/files/5aeed2ad..a6965231 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20146&range=00-01 Stats: 26 lines in 1 file changed: 5 ins; 6 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20146/head:pull/20146 PR: https://git.openjdk.org/jdk/pull/20146 From kevinw at openjdk.org Fri Jul 12 09:16:05 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 09:16:05 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 02:23:02 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting > > test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java line 171: > >> 169: if (!messageReceived) { >> 170: throw new TestFailure("No Notification received."); >> 171: } else { > > Nit: The "else" is not really needed. Removing it will simplify the change diff. ok yes > test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001.java line 180: > >> 178: >> 179: log.display("poolObjectName : " + poolObjectName + >> 180: " resultObjectName : " + resultObjectName); > > Nit: It'd be nice to fix the incorrect indent (it was in original code). right, have made a formatting update ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20146#discussion_r1675563598 PR Review Comment: https://git.openjdk.org/jdk/pull/20146#discussion_r1675563943 From jpai at openjdk.org Fri Jul 12 09:28:19 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Jul 2024 09:28:19 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Message-ID: Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. ------------- Commit messages: - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Changes: https://git.openjdk.org/jdk/pull/20154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334167 Stats: 152 lines in 3 files changed: 74 ins; 37 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/20154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20154/head:pull/20154 PR: https://git.openjdk.org/jdk/pull/20154 From alanb at openjdk.org Fri Jul 12 09:28:52 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Jul 2024 09:28:52 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v4] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: On Wed, 10 Jul 2024 20:10:13 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Addressed @AlanBateman's new suggestions Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20011#pullrequestreview-2174286901 From stuefe at openjdk.org Fri Jul 12 09:41:52 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 12 Jul 2024 09:41:52 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v4] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: <76NWu30CYLc4go6cV1iCEbfPZ6t_Y5oc3ypwhB1LKrI=.4f76ad66-e19b-4b59-96e1-ff7aaf7d1089@github.com> On Wed, 10 Jul 2024 20:10:13 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. >> >> E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. >> >> The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). >> >> The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. >> >> By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool ... > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Addressed @AlanBateman's new suggestions Last version still looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2225204396 From kevinw at openjdk.org Fri Jul 12 09:43:51 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 09:43:51 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Thanks - I was trying to make the simple "obvious" correction. The jump is from the fact that nobody currently creates an empty CmdLine, to a ruling that nobody ever can in the future. There aren't many places that create these CmdLine objects, and we don't expect much new code to use it, but there was an example of a new usage recently. I don't object to making the additional change, haven't got to it yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2225207843 From rkennke at openjdk.org Fri Jul 12 09:55:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 09:55:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp I've reviewed and tested some earlier versions of this change in the context of Lilliput, and haven't encountered any showstopping problems. Very nice work! When you say 'This patch has been evaluated to be performance neutral when UseObjectMonitorTable is turned off (the default).' - what does the performance look like with +UOMT? How does it compare to -UOMT? I've only reviewed the platform-specific changes so far. Mostly looks good, I only have some relatively minor remarks. Will review the shared code changes separately. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318: > 316: > 317: // Loop after unrolling, advance iterator. > 318: increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); Maybe I am misreading this but... in the unroll loop you avoid emitting the increment on the last iteration, but then you emit it explicitely here? Wouldn't it be cleaner to do it in the unroll loop always and elide the explicit increment after loop? src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > 341: const Register t3_owner = t3; > 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); > 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > 672: > 673: // Loop after unrolling, advance iterator. > 674: increment(t, in_bytes(OMCache::oop_to_oop_difference())); Same issue as in aarch64 code. ------------- Changes requested by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174300266 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675587650 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675597362 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675605009 From ayang at openjdk.org Fri Jul 12 09:56:51 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Jul 2024 09:56:51 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v3] In-Reply-To: <0bOEaMQ75JB0T22pbSsMEP1UV7lh1pUHoGjgTkold-w=.bfdbb2f7-010d-4d24-ab79-7fc40aadc929@github.com> References: <0bOEaMQ75JB0T22pbSsMEP1UV7lh1pUHoGjgTkold-w=.bfdbb2f7-010d-4d24-ab79-7fc40aadc929@github.com> Message-ID: On Fri, 12 Jul 2024 01:22:28 GMT, Guoxiong Li wrote: >> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 446: >> >>> 444: } >>> 445: return result; // Could be null if we are out of space. >>> 446: } >> >> I notice the method `PSOldGen::allocate` can expand the size of the old gen, but the method `PSYoungGen::allocate` can't expand the size of the young gen. It is similar to a bug [1] in Serial. Fortunately, the size of the young generation can be resized during Parallel GC if the option `UseAdaptiveSizePolicy` is `true`. When the `UseAdaptiveSizePolicy` is set to `false` manually by the user, I suspect it is a bug in Parallel because of the unexpanded young generation size. >> >> [1] https://bugs.openjdk.org/browse/JDK-8333386 > > @albertnetymk Do you think whether we need to expand young generation during allocation (both Serial and Parallel)? In Serial, `UseAdaptiveSizePolicy` is not used, so it is indeed a bug in Serial (the young generation can't be resized and is always the initial size). Due to the internal structure (eden/survivor) of young-gen, it's not super easy to expand young-gen during allocation like old-gen. Need a dedicated ticket to properly evaluate its cost/benefit. > Serial (the young generation can't be resized and is always the initial size). That sounds like a definite bug; at least young-gen should be resizable during young-gc/full-gc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20077#discussion_r1675613933 From rkennke at openjdk.org Fri Jul 12 10:14:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 10:14:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2225260710 From aboldtch at openjdk.org Fri Jul 12 10:54:23 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 10:54:23 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v7] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Cleanup c2 cache lookup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/15997bc3..e1eb8c95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=05-06 Stats: 12 lines in 2 files changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Fri Jul 12 10:54:24 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 10:54:24 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:32:44 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318: > >> 316: >> 317: // Loop after unrolling, advance iterator. >> 318: increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); > > Maybe I am misreading this but... in the unroll loop you avoid emitting the increment on the last iteration, but then you emit it explicitely here? Wouldn't it be cleaner to do it in the unroll loop always and elide the explicit increment after loop? You are correct. It is a leftover from when it was possible to tweak the number of unrolled lookups as well as whether it should loop the tail. Fixed. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > >> 341: const Register t3_owner = t3; >> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; > > That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. I see. I tend to prefer uniform initialization as it makes narrowing conversions illegal. I remember `uniform initialization` coming up in some previous PR as well. It is really only neccesary for some types of templated code, but it does also makes easier to not make mistakes in the general case (as long as you avoid `std::initializer_list`, which I think we explicitly forbid in our coding guidelines). I do not recall what the conclusion of that discussion was. But maybe it was that this feature is to exotic and foreign for hotspot. I prefer it tough. Even if I fail to consistently use it. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > >> 672: >> 673: // Loop after unrolling, advance iterator. >> 674: increment(t, in_bytes(OMCache::oop_to_oop_difference())); > > Same issue as in aarch64 code. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675676768 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675676879 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675677068 From aboldtch at openjdk.org Fri Jul 12 11:08:53 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 11:08:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote: > When you say 'This patch has been evaluated to be performance neutral when UseObjectMonitorTable is turned off (the default).' - what does the performance look like with +UOMT? How does it compare to -UOMT? Most benchmarks are unaffected as they do not use any contended locking or wait/notify. Some see improvements and some show regressions. The most significant regressions are in `DaCapo-xalan` which is very sensitive to the timing of enter. It seems to rely quite heavily on how fast you can get to `ObjectMonitor::TrySpin` as well as the exact behaviour of this spinning. Then there are all the workloads which have not been tested in all these benchmark suites. The hope is to be able to incrementally iterate on the performance of the worst outliers. > Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right? My understanding (and shared hope) is that this is the ambition. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2225341285 From aph at openjdk.org Fri Jul 12 12:08:55 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 12 Jul 2024 12:08:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > >> 341: const Register t3_owner = t3; >> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; > > That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. I agree with @rkennke . When we wrote the AArch64 MacroAssembler we were concentrating on readability and familiarity, and this separate declaration and use, with unusual syntax, IMO makes life harder for the reader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675751592 From simonis at openjdk.org Fri Jul 12 12:13:07 2024 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 12 Jul 2024 12:13:07 GMT Subject: Integrated: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors In-Reply-To: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: <5iFQ2S2ULy3VihTASjUgT6so-yvXFUDWAmzcz2N2smE=.28e0bd31-2ce0-4120-9e93-b04cedf94af4@github.com> On Wed, 3 Jul 2024 16:14:31 GMT, Volker Simonis wrote: > Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virtual Machine Tool Interface (JVMTI) also introduced in Java 5. But because the `java.lang.instrument` API is a pure Java API and uses Java classes to instrument Java classes it imposes some usage restrictions which are not very well documented in its API specification. > > E.g. the section on ["Bytecode Instrumentation"](https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#bci) in the JVMTI specification explicitly warns that special "*Care must be taken to avoid perturbing dependencies, especially when instrumenting core classes*". The risk of such "perturbing dependencies" is obviously much higher in a Java API like `java.lang.instrument`, but a more detailed explanation and warning is missing from its API documentation. > > The most evident class file transformation restriction is that while a class A is being loaded and transformed it is not possible to use this same class directly or transitively from the `ClassFileTransformer::transform()` method. Violating this rule will result in a `ClassCircularityError` (the exact error type is disputable as can be seen in [8164165: JVM throws incorrect exception when ClassFileTransformer.transform() triggers class loading of class already being loaded](https://bugs.openjdk.org/browse/JDK-8164165), but the result would be a `LinkageError in any case). > > The risk to run into such a `ClassCircularityError` error increases with the amount of code a transforming agent is transitively using from the `transform()` method. Using popular libraries like ASM, ByteBuddy, etc. for transformation further increases the probability of running into such issues, especially if the agent aims to transform core JDK library classes. > > By default, the occurrence of a `ClassCircularityError` in `ClassFileTransformer::transform()` will be handled gracefully with the only consequence that the current transformation target will be loaded unmodified (see `ClassFileTransformer` API spec: "*throwing an exception has the same effect as returning null*"). But unfortunately, it can also have a subtle but at the same time much more far-reaching consequence. If the `ClassCircularityError` occurs during the resolution of a constant pool entry in another, ... This pull request has now been integrated. Changeset: eec0e155 Author: Volker Simonis URL: https://git.openjdk.org/jdk/commit/eec0e155f303ff4bbdab172765ca7c92c2b94cbd Stats: 21 lines in 1 file changed: 17 ins; 0 del; 4 mod 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors Reviewed-by: alanb, stuefe, liach ------------- PR: https://git.openjdk.org/jdk/pull/20011 From simonis at openjdk.org Fri Jul 12 12:13:07 2024 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 12 Jul 2024 12:13:07 GMT Subject: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2] In-Reply-To: References: <31A-LrXAIa_-ygSeXRamUQllHowqgmkZ1h1587F3B6s=.8bc8f967-1d90-4215-b695-637cbdd36a08@github.com> Message-ID: <3hk2EFFXFId8N_952DqZwD8aYz4pcVNjMw7G6LqEcBQ=.9f5162a2-6ece-417f-8e10-2c1f898554bb@github.com> On Tue, 9 Jul 2024 12:17:25 GMT, Alan Bateman wrote: >> @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? >> >> Thank you and best regards, >> Volker > >> @AlanBateman would you mind having a quick look at this trivial, documentation-only PR and let me know if you're OK with it? > > (Catching up as I was away for a few days). > > I agree it would be useful to have an API note on this topic. There were several reports of deadlocks, ClassCircularityError, and other hard to diagnose issues when support for instrumentation was originally introduced in JDK 5. I think agent maintainers learned to exclude many of the core classes in java.base but that is always a moving target and there have been a few more sightings/reports recently (maybe due to newer features doing more in Java rather than in the VM). > > I agree that the ClassFileTransformer class description is the best place for this. My initial reaction was to wonder about the j.l.instrument package description but it is more focused on starting agents and the JAR file attributes so I think your proposed location is best.. > > As regards the text then it might be better to start with a sentence to say that the "transform" method may be called from critical points in JDK core classes or called to transform JDK core classes. You've got some of this in second sentence but I think better to lead with it before revealing one of the several possible things that can happen. I think part of the lead in needs to say "great care must be taken" or something like that to get across the point that the ClassFileTransformer implementor has the potential to cause many possible issues. For the same class and linkage error then probably best to not use the phrase "transitively requires" as it's too close "requires transitive" used in module declarations. > > Note that the `@jvms` tag can be used to reference the JVMS section. You'll see a few examples in other classes. Thanks everybody for the quick and helpful reviews and @AlanBateman for opening [JDK-8336296](https://bugs.openjdk.org/browse/JDK-8336296) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20011#issuecomment-2225447830 From gli at openjdk.org Fri Jul 12 12:17:52 2024 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 12 Jul 2024 12:17:52 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v4] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 18:06:34 GMT, Albert Mingkun Yang wrote: >> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. >> >> The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. >> >> Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into pgc-vm-operation > - review > - review > - Merge branch 'master' into pgc-vm-operation > - pgc-vm-operation Marked as reviewed by gli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20077#pullrequestreview-2174586077 From coleenp at openjdk.org Fri Jul 12 12:50:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Jul 2024 12:50:52 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v7] In-Reply-To: References: Message-ID: <6Aa4oWKwpgo9Br75tCLj3AGQLxP9Rw2dgjzOXJQ6CTo=.e92e83f5-e4b3-43d8-8e89-3349de99524d@github.com> On Fri, 12 Jul 2024 10:54:23 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup c2 cache lookup Thank you for making the argument change. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174647655 From ayang at openjdk.org Fri Jul 12 13:01:59 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Jul 2024 13:01:59 GMT Subject: RFR: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC [v4] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 18:06:34 GMT, Albert Mingkun Yang wrote: >> Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. >> >> The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. >> >> Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into pgc-vm-operation > - review > - review > - Merge branch 'master' into pgc-vm-operation > - pgc-vm-operation Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20077#issuecomment-2225527435 From ayang at openjdk.org Fri Jul 12 13:02:00 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Jul 2024 13:02:00 GMT Subject: Integrated: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC In-Reply-To: References: Message-ID: <2rPj9VK03GeaMLDlBBlNBKwNQCLPWNk-cbsLN_G3ymA=.a932a4b7-185d-46b3-acac-4a27ff4a1ee8@github.com> On Mon, 8 Jul 2024 16:18:22 GMT, Albert Mingkun Yang wrote: > Similar cleanup as https://github.com/openjdk/jdk/pull/19056 but in Parallel. As a result, the corresponding code in `SerialHeap` and `ParallelScavengeHeap` share much similarity. > > The easiest way to review is to start from these two VM operations, `VM_ParallelCollectForAllocation` and `VM_ParallelGCCollect` and follow the new code directly, where one can see how allocation-failure triggers various GCs with different collection efforts. > > Test: tier1-6; perf-neural for dacapo, specjvm2008, specjbb2015 and cachestresser. This pull request has now been integrated. Changeset: 34d8562a Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/34d8562a913b8382601e4c0c31ad34a663b9ec0a Stats: 342 lines in 14 files changed: 88 ins; 169 del; 85 mod 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC Reviewed-by: gli, zgu ------------- PR: https://git.openjdk.org/jdk/pull/20077 From aboldtch at openjdk.org Fri Jul 12 13:06:40 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 13:06:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v8] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Avoid uniform initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/e1eb8c95..cccffeda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=06-07 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Fri Jul 12 13:06:40 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 12 Jul 2024 13:06:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: >> >>> 341: const Register t3_owner = t3; >>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 : checked_cast(markWord::monitor_value)); >>> 343: const Address owner_address{t1_monitor, ObjectMonitor::owner_offset() - monitor_tag}; >> >> That may be just me, but I found that syntax weird. I first needed to look-up what the {}-initializer actually means. Hiccups like this reduce readability, IMO. I'd prefer the normal ()-init for the Address like we seem to do everywhere else. > > I agree with @rkennke . When we wrote the AArch64 MacroAssembler we were concentrating on readability and familiarity, and this separate declaration and use, with unusual syntax, IMO makes life harder for the reader. Fair enough. ? _To me uniform initialization is just safer less problematic way of expressing the same thing._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675828324 From j.bachorik at gmail.com Fri Jul 12 15:19:04 2024 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Fri, 12 Jul 2024 17:19:04 +0200 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: <1b81179e-6d61-4a61-a1f5-6c178a437b1b@oracle.com> References: <1b81179e-6d61-4a61-a1f5-6c178a437b1b@oracle.com> Message-ID: On Wed, Jul 10, 2024 at 5:53?PM Alan Bateman wrote: > On 10/07/2024 16:37, Jaroslav Bachorik wrote: > > : > > This may not always be possible. Some systems have rather complex and > inlexible launchers - for example Apache Spark with its clusters, drivers > and executors and automatic distribution of resources. For that system, if > one needs to add an on-startup Java agent via `-javaagent` option the only > way is to modify the setup which will add `-javaagent` to all components, > pointing to a location where the resource distribution service should be > putting the agent jar. However, mistakes happen and the jar may not be > there. But because usually the agent is providing tracing or metrics > collection, which are all optional, it is not feasible to hard-crash the > Java process because of not being able to load the Java agent. > > Forn this PoV the proposal to allow optionally ignoring non-existing Java > agent sounds as a very pragmatic solution, > > > The issue of injecting CLI options to start tool agents was explored back > in JSR 163, that is the reason for environment variables such as > JAVA_TOOL_OPTIONS. Broader support was added in JDK 9 with > JDK_JAVA_OPTIONS, @argfile support, and support for GNU style options. So > the JDK has several features to augment the command line or options. > > Has anyone tried to work with the Apache Spark (or other projects) to make > use of any of this support so that additional CLI options are conditionally > used? > I might have not been completely clear about this use case. The problem is that the agent must be distributed to each node of the cluster and if, for whatever reason, there is an issue with the process or the there is a typo in the path of the agent specified in the launcher arguments, JVM will hard-fail, which is quite a steep price to pay. I fail to see how JAVA_TOOL_OPTIONS, JDK_JAVA_OPTIONS or @argfile would help here - the agent location would always be statically defined and hence prone to crash JVM if the agent is not at the expected location. The only way I can imagine this could work would be for eg. Spark (or any other service affected by the mismatch of the configuration and the agent file) to have a special 'agent' configuration in the launcher which would then be dynamically translated into `-javaagent:` JVM argument, given that the agent file is accessible. TBH, I have no stakes in this any more - it's just I've always found crashing on missing java agent rather baffling experience. -JB- > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at openjdk.org Fri Jul 12 16:18:02 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:02 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 05:57:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update arguments.cpp Here comes my first-pass review of the shared code. (Man, I hope we can get rid of UOMT soon, again...) src/hotspot/share/oops/instanceKlass.cpp line 1090: > 1088: > 1089: // Step 2 > 1090: // If we were to use wait() instead of waitUninterruptibly() then This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. src/hotspot/share/oops/markWord.cpp line 27: > 25: #include "precompiled.hpp" > 26: #include "oops/markWord.hpp" > 27: #include "runtime/basicLock.inline.hpp" I don't think this include is needed (at least not by the changed code parts, I haven't checked existing code). src/hotspot/share/runtime/arguments.cpp line 1820: > 1818: warning("New lightweight locking not supported on this platform"); > 1819: } > 1820: if (UseObjectMonitorTable) { Uhm, wait a second. That list of platforms covers all existing platforms anyway, so the whole block could be removed? Or is there a deeper meaning here that I don't understand? src/hotspot/share/runtime/basicLock.cpp line 37: > 35: if (mon != nullptr) { > 36: mon->print_on(st); > 37: } I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. src/hotspot/share/runtime/basicLock.inline.hpp line 45: > 43: return reinterpret_cast(get_metadata()); > 44: #else > 45: // Other platforms does not make use of the cache yet, If it's not used, why does it matter to special case the code here? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 28: > 26: > 27: #include "classfile/vmSymbols.hpp" > 28: #include "javaThread.inline.hpp" This include is incorrect (and my IDE says it's not needed). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 31: > 29: #include "jfrfiles/jfrEventClasses.hpp" > 30: #include "logging/log.hpp" > 31: #include "logging/logStream.hpp" Include of logStream.hpp not needed? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 58: > 56: > 57: // > 58: // Lightweight synchronization. This comment doesn't really say anything. Either remove it, or add a nice summary of how LW locking and OM table stuff works. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: > 78: > 79: ConcurrentTable* _table; > 80: volatile size_t _table_count; Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... src/hotspot/share/runtime/lightweightSynchronizer.cpp line 88: > 86: > 87: public: > 88: Lookup(oop obj) : _obj(obj) {} Make explicit? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 97: > 95: > 96: bool equals(ObjectMonitor** value) { > 97: // The entry is going to be removed soon. What does this comment mean? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 112: > 110: > 111: public: > 112: LookupMonitor(ObjectMonitor* monitor) : _monitor(monitor) {} Make explicit? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: > 157: static size_t min_log_size() { > 158: // ~= log(AvgMonitorsPerThreadEstimate default) > 159: return 10; Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. Or why not use AvgMonitorsPerThreadEstimate directly? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 349: > 347: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); > 348: > 349: if (try_read) { All the callers seem to pass try_read = true. Why do we have the branch at all? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401: > 399: > 400: if (inserted) { > 401: // Hopefully the performance counters are allocated on distinct It doesn't look like the counters are on distinct cache lines (see objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to investigate it later? The comment here is a bit misplaced, IMO. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 473: > 471: int _length; > 472: > 473: void do_oop(oop* o) final { C++ always provides something to learn - C++ has got a final keyword! :-) Looks like a reasonable use of it here, though. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477: > 475: if (obj->mark_acquire().has_monitor()) { > 476: if (_length > 0 && _contended_oops[_length-1] == obj) { > 477: // assert(VM_Version::supports_recursive_lightweight_locking(), "must be"); Uncomment or remove assert? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 554: > 552: bool _no_safepoint; > 553: union { > 554: struct {} _dummy; Uhh ... Why does this need to be wrapped in a union and struct? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: > 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); > 562: if (_no_safepoint) { > 563: ::new (&_nsv) NoSafepointVerifier(); I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec _no_safepoint_count(). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 748: > 746: } > 747: > 748: // Fast-locking does not use the 'lock' argument. I believe the comment is outdated. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 969: > 967: > 968: for (;;) { > 969: // Fetch the monitor from the table Wrong intendation. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1157: > 1155: // enter can block for safepoints; clear the unhandled object oop > 1156: PauseNoSafepointVerifier pnsv(&nsv); > 1157: object = nullptr; What is the point of that statement? object is not an out-arg (afaict), and not used subsequently. src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: > 66: static void exit(oop object, JavaThread* current); > 67: > 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* src/hotspot/share/runtime/lockStack.inline.hpp line 232: > 230: oop obj = monitor->object_peek(); > 231: assert(obj != nullptr, "must be alive"); > 232: assert(monitor == LightweightSynchronizer::get_monitor_from_table(JavaThread::current(), obj), "must be exist in table"); "must be exist in table" -> "must exist in table" src/hotspot/share/runtime/objectMonitor.cpp line 56: > 54: #include "runtime/safepointMechanism.inline.hpp" > 55: #include "runtime/sharedRuntime.hpp" > 56: #include "runtime/synchronizer.hpp" This include is not used. src/hotspot/share/runtime/objectMonitor.hpp line 193: > 191: ObjectWaiter* volatile _WaitSet; // LL of threads wait()ing on the monitor > 192: volatile int _waiters; // number of waiting threads > 193: private: You can now also remove the 'private:' here src/hotspot/share/runtime/synchronizer.cpp line 390: > 388: > 389: static bool useHeavyMonitors() { > 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) Why are those if-defs here? Why is ARM excluded? ------------- Changes requested by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2174478048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675695457 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675696406 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675704824 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675707735 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675711809 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675744474 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675745048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676111067 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675773683 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675747483 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675765460 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675766088 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675781420 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675791687 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675799897 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675803217 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675805690 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675824394 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675832868 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675854207 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675876915 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675932005 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675936943 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676107048 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676112375 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676125325 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676140201 From rkennke at openjdk.org Fri Jul 12 16:18:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:03 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v3] In-Reply-To: <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> References: <5CNKzDumOf1MJQXM9OBHQh0Mj7eLv2ONio1V-AXeSJI=.54302b45-2dd2-4f18-a094-6b2c6a59517c@github.com> <-hS6aTxhzI_HzVegg0EziUtGxdq6orpF9s1rF3l2hZY=.0c4296b2-d27a-4578-a160-d17b65163655@github.com> Message-ID: On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >> This reverts commit 2814350370cf142e130fe1d38610c646039f976d. > > src/hotspot/share/opto/library_call.cpp line 4620: > >> 4618: Node *unlocked_val = _gvn.MakeConX(markWord::unlocked_value); >> 4619: Node *chk_unlocked = _gvn.transform(new CmpXNode(lmasked_header, unlocked_val)); >> 4620: Node *test_not_unlocked = _gvn.transform(new BoolNode(chk_unlocked, BoolTest::ne)); > > I don't really know what this does. Someone from the c2 compiler group should look at this. Yes, that looks correct. I'm familiar with this code because I messed with it in my attempts to implement compact identity hashcode in Lilliput2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1675699672 From rkennke at openjdk.org Fri Jul 12 16:18:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jul 2024 16:18:03 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/runtime/synchronizer.cpp line 390: > >> 388: >> 389: static bool useHeavyMonitors() { >> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) > > Why are those if-defs here? Why is ARM excluded? Oh I see, you only moved this up. Still a bit puzzling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676142470 From cjplummer at openjdk.org Fri Jul 12 16:41:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 16:41:52 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20025#pullrequestreview-2175313214 From cjplummer at openjdk.org Fri Jul 12 16:41:53 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 16:41:53 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: <8fzuIYuEccEuEH1Qm4yeX4-qKLkN770Pp3HhSvyFxhA=.b2fb581b-9a31-476c-82b1-d62bb776ddf6@github.com> Message-ID: On Mon, 8 Jul 2024 21:09:49 GMT, Kevin Walls wrote: >> test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java line 239: >> >>> 237: " > ThreadUserTime = " + utime2); >>> 238: } >>> 239: */ >> >> Shouldn't this be uncommented and this bit of testing restored? It seems the only reason it was commented out is because of Solaris, which we don't need to worry about anymore. Probably best to leave this to a separate PR if you are going to restore it. > > Would have been happy to test it and bring it back, have looked into it more: > > back in jdk5u we have the same commented out code, we have never run this in general testing. > > I think it's redundant, the two calls are equivalent. > > long utime1 = mbean.getCurrentThreadUserTime(); > > "This is a convenient method for local management use and is equivalent to calling: getThreadUserTime(Thread.currentThread().getId());" > > ..which is the other time we would be comparing it with: > > long utime2 = mbean.getThreadUserTime(getId()); (in this class that extends Thread). > > I think we can presume some os-specific quirk that does not affect us today! ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20025#discussion_r1676184208 From cjplummer at openjdk.org Fri Jul 12 17:05:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 17:05:52 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> Message-ID: On Fri, 12 Jul 2024 08:02:31 GMT, Alex Menkov wrote: >> First just to clarify a general JDI feature about thread suspending and resuming. You can undo a ThreadReference.suspend() or a thread suspended as the result of an event by dong a vm.resume(). This is documented in the JDI API spec, which talks about suspendCounts and how various APIs and event delivery affect them. >> >> I was tempted to clean up these vm.resume() calls but opted not to. The point being made in the comment is that worse case thread2 was suspended by a breakpoint or thread2.suspend() and all threads were suspended by a vm.resume() (meaning thread2 could have a suspendCount of 2). Two vm.resumes() take are done to make sure thread2 gets resumed under this situation. However, one of the vm.resume calls could instead be a thread2.resume(). Doing two vm.resume() calls was probably just laziness by the original authors. It works though. >> >> However, by my accounting at any failure point thread2 never has a suspendCount > 1, so really just one vm.resume() would be enough. >> >> The original code did these two vm.resume() calls unconditionally, but they are not needed if there was no error. > > The original code had 2 vm.resume() - one on them to match vm.suspend() and 2nd one to allow debugee to continue on error. > Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2 conditional (on error). > Theoretically we can get an error when both vm and thread2 are suspended, so 2 vm.resume() looks reasonable. > Anyway resume() is a nop if the thread is not suspended After reaching the 2nd breakpoint, which suspends thread2, we do a vm.suspend(), which bumps the thread2 suspendCount to 2. However, we do a eventSet.resume() after this, lowering the suspendCount to 1, and there is no error bailout point while the suspendCount is 2. Thus only 1 vm.resume() is needed in the error handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1676208721 From kevinw at openjdk.org Fri Jul 12 17:13:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 17:13:55 GMT Subject: Integrated: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. This pull request has now been integrated. Changeset: 1f6e106b Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/1f6e106b45e5109224e13d70f1a40c9e666ec2ab Stats: 12 lines in 1 file changed: 2 ins; 9 del; 1 mod 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/20025 From kevinw at openjdk.org Fri Jul 12 17:13:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Jul 2024 17:13:55 GMT Subject: RFR: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote: > There are two similarly names tests. > Recently: > JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range > ...made a simple change to try and avoid noisy test failures. The same fix should be applied here to ThreadCpuTime.java. > > Also removing an old comment about a Solaris issue. thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20025#issuecomment-2225988005 From coleenp at openjdk.org Fri Jul 12 17:44:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Jul 2024 17:44:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:58:56 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 390: >> >>> 388: >>> 389: static bool useHeavyMonitors() { >>> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || defined(RISCV64) || defined(S390) >> >> Why are those if-defs here? Why is ARM excluded? > > Oh I see, you only moved this up. Still a bit puzzling. This code was just moved. No idea why ARM is excluded. I filed this to deal with this. https://bugs.openjdk.org/browse/JDK-8336325 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1676253183 From ron.pressler at oracle.com Fri Jul 12 19:06:12 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 12 Jul 2024 19:06:12 +0000 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: > On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote: > > This may not always be possible. Some systems have rather complex and inlexible launchers - for example Apache Spark with its clusters, drivers and executors and automatic distribution of resources. For that system, if one needs to add an on-startup Java agent via `-javaagent` option the only way is to modify the setup which will add `-javaagent` to all components, pointing to a location where the resource distribution service should be putting the agent jar. However, mistakes happen and the jar may not be there. But because usually the agent is providing tracing or metrics collection, which are all optional, it is not feasible to hard-crash the Java process because of not being able to load the Java agent. > > Forn this PoV the proposal to allow optionally ignoring non-existing Java agent sounds as a very pragmatic solution, A pragmatic solution of one problem is often ? as in this case ? the cause of other problems. A Java application may happen to run, by chance, with some classes or an agent missing, or it may not, which may manifest in a strange way. In order to better judge the pros and cons, can you please explain in as much detail as could be relevant, the difficulties involved in having different runtime scripts and/or a conditional in the script? This would be at least as pragmatic a solution, so to compare the two we need to understand why a script can be so difficult to write or change as to necessitate a change to the JDK. Going from ?my startup script is not very flexible? to ?so let?s change the JDK? is a big jump that would require a big justification. ? Ron From kbarrett at openjdk.org Fri Jul 12 19:20:51 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Jul 2024 19:20:51 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) This should be using `os::snprintf` rather than `snprintf`. Rationale is in the comment here: https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126 And yes, I know there are lots of bare uses of snprintf (about 125?), including in shared code. That's why it isn't currently in the forbidden list. There's some cleanup to do there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226218368 From sspitsyn at openjdk.org Fri Jul 12 19:35:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Jul 2024 19:35:53 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 01:50:30 GMT, Alex Menkov wrote: > The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes > > testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms The fix looks good. Posted some nits and questions. src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 57: > 55: doPrivilegedOpenProcess(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId); > 56: > 57: /* Convert jstring to C string, returns JNI_FALSE if the string has been truncated. */ Nit: It is better to have it either: "Convert jstring to C string, return JNI_FALSE ..." or "Converts jstring to C string, returns JNI_FALSE" The same applies to the comment at line 621. test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 94: > 92: HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid())); > 93: > 94: if (setFlag(vm)) { Q: Should the test fail if there an `IOException` was caught in the `setFlag()` call? test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 101: > 99: + (actualValue == null > 100: ? "null" > 101: : ("size is " + actualValue.length() + " instead of " + flagValue.length())); Q: What if value is different but size is the same? I understand the probability is very low but this is still confusing. test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 126: > 124: ex.printStackTrace(System.out); > 125: return false; > 126: } Q: Is it always the case there is no need to close the `BufferedReader` in this context? Just want to understand. ------------- PR Review: https://git.openjdk.org/jdk/pull/19780#pullrequestreview-2173973061 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1675379386 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676279668 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676373808 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676377248 From amenkov at openjdk.org Fri Jul 12 21:03:27 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 21:03:27 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:27:46 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 57: > >> 55: doPrivilegedOpenProcess(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId); >> 56: >> 57: /* Convert jstring to C string, returns JNI_FALSE if the string has been truncated. */ > > Nit: It is better to have it either: > "Convert jstring to C string, return JNI_FALSE ..." > or > "Converts jstring to C string, returns JNI_FALSE" > > The same applies to the comment at line 621. Fixed > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 94: > >> 92: HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid())); >> 93: >> 94: if (setFlag(vm)) { > > Q: Should the test fail if there an `IOException` was caught in the `setFlag()` call? Currently Attach operations have restriction for argument size, so setFlag() is expected to fail for long values. This fix adds AttachOperationFailedException for the case on windows, linux/bsd/aix implementations throw generic IOException. (There is [JDK-8334168](https://bugs.openjdk.org/browse/JDK-8334168) to throw AttachOperationFailedException instead of IOException if an argument is too long on other platforms) > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 101: > >> 99: + (actualValue == null >> 100: ? "null" >> 101: : ("size is " + actualValue.length() + " instead of " + flagValue.length())); > > Q: What if value is different but size is the same? > I understand the probability is very low but this is still confusing. I updated the code to check if the value was truncated > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 126: > >> 124: ex.printStackTrace(System.out); >> 125: return false; >> 126: } > > Q: Is it always the case there is no need to close the `BufferedReader` in this context? Just want to understand. We can get exception here only if vm.setFlag() throws it. In the case BufferedReader is not yet constructed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676454684 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676437197 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676454322 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676454488 From amenkov at openjdk.org Fri Jul 12 21:03:26 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Jul 2024 21:03:26 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: > The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes > > testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19780/files - new: https://git.openjdk.org/jdk/pull/19780/files/0ffedb14..be66602d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19780&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19780&range=00-01 Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19780/head:pull/19780 PR: https://git.openjdk.org/jdk/pull/19780 From larry.cable at oracle.com Fri Jul 12 21:32:07 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Fri, 12 Jul 2024 14:32:07 -0700 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: <45c8efd2-94cb-4a50-83a1-23fe71337865@oracle.com> On 7/12/24 12:06 PM, Ron Pressler wrote: > >> On 10 Jul 2024, at 16:37, Jaroslav Bachorik wrote: >> >> This may not always be possible. Some systems have rather complex and inlexible launchers - for example Apache Spark with its clusters, drivers and executors and automatic distribution of resources. For that system, if one needs to add an on-startup Java agent via `-javaagent` option the only way is to modify the setup which will add `-javaagent` to all components, pointing to a location where the resource distribution service should be putting the agent jar. However, mistakes happen and the jar may not be there. But because usually the agent is providing tracing or metrics collection, which are all optional, it is not feasible to hard-crash the Java process because of not being able to load the Java agent. >> >> Forn this PoV the proposal to allow optionally ignoring non-existing Java agent sounds as a very pragmatic solution, > A pragmatic solution of one problem is often ? as in this case ? the cause of other problems. A Java application may happen to run, by chance, with some classes or an agent missing, or it may not, which may manifest in a strange way. > > In order to better judge the pros and cons, can you please explain in as much detail as could be relevant, the difficulties involved in having different runtime scripts and/or a conditional in the script? This would be at least as pragmatic a solution, so to compare the two we need to understand why a script can be so difficult to write or change as to necessitate a change to the JDK.*Going from ?my startup script is not very flexible? to ?so let?s > change the JDK? is a big jump that would require a big justification. * > ? Ron +1! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcubed at openjdk.org Fri Jul 12 22:38:57 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Jul 2024 22:38:57 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error Is there any chance that all the `Breakpint` typos can be fixed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2226446333 From dcubed at openjdk.org Fri Jul 12 22:38:58 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Jul 2024 22:38:58 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> <1dQzf5fgxidtvimntaO5Ql0o--ehCAFjCxV7KV-t5wY=.74f093e8-2f09-4d2b-8ead-66b6a5e77bc3@github.com> Message-ID: On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer wrote: >> The original code had 2 vm.resume() - one on them to match vm.suspend() and 2nd one to allow debugee to continue on error. >> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2 conditional (on error). >> Theoretically we can get an error when both vm and thread2 are suspended, so 2 vm.resume() looks reasonable. >> Anyway resume() is a nop if the thread is not suspended > > After reaching the 2nd breakpoint, which suspends thread2, we do a vm.suspend(), which bumps the thread2 suspendCount to 2. However, we do a eventSet.resume() after this, lowering the suspendCount to 1, and there is no error bailout point while the suspendCount is 2. Thus only 1 vm.resume() is needed in the error handling. I think all this discussion about the number of `vm.resume()` calls that are needed or not needed and the fact that one of those `vm.resume()` calls could be replaced by a thread2.resume() call _perfectly_ illustrates just how complicated this test is. Thanks for going thru the effort to get rid of the `sleep()` call. I appreciate it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1676519121 From dcubed at openjdk.org Fri Jul 12 23:20:55 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Jul 2024 23:20:55 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Is it useful to allow (but ignore) an "empty" command to perhaps allow perf analysis of the dcmd mechanism? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2226515899 From dcubed at openjdk.org Fri Jul 12 23:37:58 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Jul 2024 23:37:58 GMT Subject: RFR: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 03:24:42 GMT, SendaoYan wrote: > Hi all, > Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after [JDK-8335743](https://bugs.openjdk.org/browse/JDK-8335743). I think the new failures was testcase bug. > > https://github.com/openjdk/jdk/blob/627a32d6722c92f814c1ddd1c2fdf9a3b28cd655/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L112 > Locals are not always available, e.g., compiled native frames have no scope so there are no locals. So the output `- waiting on ` also acceptable. > > The change has been verified by -Xmixed/-Xcomp(c2)/-Xcomp -XX:TieredStopAtLevel=1(c1), only change the testcase, no risk. For noisy test failures, we often waive the 24 hour rule in order to quiet down the CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20151#issuecomment-2226526095 From cjplummer at openjdk.org Fri Jul 12 23:47:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Jul 2024 23:47:52 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Fri, 12 Jul 2024 22:36:56 GMT, Daniel D. Daugherty wrote: > Is there any chance that all the `Breakpint` typos can be fixed? There was only one and I fixed it already. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2226537454 From cjplummer at openjdk.org Sat Jul 13 00:41:56 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 13 Jul 2024 00:41:56 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 21:03:26 GMT, Alex Menkov wrote: >> The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes >> >> testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 79: > 77: // Value length exceeds 1K. > 78: Test withLongValue() { > 79: flagValue = generateValue(1024 + 1); Shouldn't we also be testing exactly 1024 and expect it to work? test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 98: > 96: > 97: if (!flagValue.equals(actualValue)) { > 98: String msg = "Actual values is different: " Suggestion: String msg = "Actual value is different: " test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 159: > 157: private static Test test(LingeredApp app) { > 158: return new Test(app); > 159: } I think the method would be better off placed right after main(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676583710 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676427158 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676427832 From amenkov at openjdk.org Sat Jul 13 01:40:02 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 13 Jul 2024 01:40:02 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 20:25:21 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 98: > >> 96: >> 97: if (!flagValue.equals(actualValue)) { >> 98: String msg = "Actual values is different: " > > Suggestion: > > String msg = "Actual value is different: " This was fixed in the previous commit > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 159: > >> 157: private static Test test(LingeredApp app) { >> 158: return new Test(app); >> 159: } > > I think the method would be better off placed right after main(). ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676652083 PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676652191 From amenkov at openjdk.org Sat Jul 13 01:48:56 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 13 Jul 2024 01:48:56 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 00:39:02 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 79: > >> 77: // Value length exceeds 1K. >> 78: Test withLongValue() { >> 79: flagValue = generateValue(1024 + 1); > > Shouldn't we also be testing exactly 1024 and expect it to work? good question! tried to make it 1024 and it does not work! Windows VirtualMachineImpl has one more issue - it uses 1024 char buffers, but it should be (1024 + 1) as AttachListener does (1 extra char to 0-terminator), so maximum argument size on windows is 1023. Will fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676663900 From jwaters at openjdk.org Sat Jul 13 05:14:52 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:14:52 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote: > This should be using `os::snprintf` rather than `snprintf`. Rationale is in the comment here: > > https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126 > > And yes, I know there are lots of bare uses of snprintf (about 125?), including in shared code. That's why it isn't currently in the forbidden list. There's some cleanup to do there. Ah, I'd assumed that the places where bare _snprintf was used had a reason for using it directly. I'll change all the usages in this Pull Request to use os::snprintf ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226776993 From jwaters at openjdk.org Sat Jul 13 05:34:24 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:34:24 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: USe os::snprintf in HotSpot ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/20a8e2a0..1bd6bc09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From jwaters at openjdk.org Sat Jul 13 05:36:50 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 13 Jul 2024 05:36:50 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) I would add a FORBID_C_FUNCTION for _snprintf for Windows, but unfortunately that would be completely useless since there's no way to restrict methods on Visual Studio ------------- PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2226782288 From sspitsyn at openjdk.org Sat Jul 13 06:24:52 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 13 Jul 2024 06:24:52 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 20:37:49 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 94: >> >>> 92: HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid())); >>> 93: >>> 94: if (setFlag(vm)) { >> >> Q: Should the test fail if there an `IOException` was caught in the `setFlag()` call? > > Currently Attach operations have restriction for argument size, so setFlag() is expected to fail for long values. > This fix adds AttachOperationFailedException for the case on windows, linux/bsd/aix implementations throw generic IOException. > (There is [JDK-8334168](https://bugs.openjdk.org/browse/JDK-8334168) to throw AttachOperationFailedException instead of IOException if an argument is too long on other platforms) Not sure, you've answered my question. Let me ask it differently. Here I do not care about other exceptions on other platforms. The `setFlag()` can catch an `IOException` at the line 126 and return false in that case. The `run()` method at the line 94 is swallowing the `false` value as there is no `else` statement. So, we just ignore the `IOException` and do not test anything. My question is: Why don't we throw a `RuntimeException` in the case the `setFlag()` returned `false`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1676769508 From mgronlun at openjdk.org Sat Jul 13 14:53:19 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sat, 13 Jul 2024 14:53:19 GMT Subject: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Message-ID: Greetings, Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds assertions about the JFR bit tag state machine. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8334781 Changes: https://git.openjdk.org/jdk/pull/20171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334781 Stats: 34 lines in 7 files changed: 17 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20171/head:pull/20171 PR: https://git.openjdk.org/jdk/pull/20171 From egahlin at openjdk.org Sat Jul 13 16:32:50 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Sat, 13 Jul 2024 16:32:50 GMT Subject: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 14:47:21 GMT, Markus Gr?nlund wrote: > Greetings, > > Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds assertions about the JFR bit tag state machine. > > Testing: jdk_jfr, stress testing > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20171#pullrequestreview-2176439194 From j.bachorik at gmail.com Sun Jul 14 15:56:02 2024 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Sun, 14 Jul 2024 17:56:02 +0200 Subject: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: On Fri 12. 7. 2024 at 21:06, Ron Pressler wrote: > > > > On 10 Jul 2024, at 16:37, Jaroslav Bachorik > wrote: > > > > This may not always be possible. Some systems have rather complex and > inlexible launchers - for example Apache Spark with its clusters, drivers > and executors and automatic distribution of resources. For that system, if > one needs to add an on-startup Java agent via `-javaagent` option the only > way is to modify the setup which will add `-javaagent` to all components, > pointing to a location where the resource distribution service should be > putting the agent jar. However, mistakes happen and the jar may not be > there. But because usually the agent is providing tracing or metrics > collection, which are all optional, it is not feasible to hard-crash the > Java process because of not being able to load the Java agent. > > > > Forn this PoV the proposal to allow optionally ignoring non-existing > Java agent sounds as a very pragmatic solution, > > A pragmatic solution of one problem is often ? as in this case ? the cause > of other problems. A Java application may happen to run, by chance, with > some classes or an agent missing, or it may not, which may manifest in a > strange way. > > In order to better judge the pros and cons, can you please explain in as > much detail as could be relevant, the difficulties involved in having > different runtime scripts and/or a conditional in the script? This would be > at least as pragmatic a solution, so to compare the two we need to > understand why a script can be so difficult to write or change as to > necessitate a change to the JDK. Going from ?my startup script is not very > flexible? to ?so let?s change the JDK? is a big jump that would require a > big justification. I have unwittingly became the advocate for this change although I really don?t care at this moment. I just thought to bring up my painful experience when I had to deal with Yarn (clustering solution) and Apache Spark. You can read more about that at https://spark.apache.org/docs/latest/running-on-yarn.html#spark-properties - I am not going to transcribe all of that here. The bottom line is that the clustering solution allows specifying JVM options and extra resources that will be distributed to all nodes. Hence, if you want to add an agent, you need to add the jvn options to point to the location where the agent jar (resource) will be placed. As you can expect, things can break and you end up killing your Spark pipeline instead of running without observably ???? However, I don?t understand the argument that running without agent can lead to subtle errors. Agents were always meant to be optional - the core application functionality should not really be dependent on the agent availability. But, obviously, I was wrong all this time. -JB- > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From aboldtch at openjdk.org Mon Jul 15 00:50:30 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Jul 2024 00:50:30 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: > When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. > > This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. > > A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). > > This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). > > Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. > > # Cleanups > > Cleaned up displaced header usage for: > * BasicLock > * Contains some Zero changes > * Renames one exported JVMCI field > * ObjectMonitor > * Updates comments and tests consistencies > > # Refactoring > > `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. > > The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. > > _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ > > # LightweightSynchronizer > > Working on adapting and incorporating the following section as a comment in the source code > > ## Fast Locking > > CAS on locking bits in markWord. > 0b00 (Fast Locked) <--> 0b01 (Unlocked) > > When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. > > If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf... Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: - Remove try_read - Add explicit to single parameter constructors - Remove superfluous access specifier - Remove unused include - Update assert message OMCache::set_monitor - Fix indentation - Remove outdated comment LightweightSynchronizer::exit - Remove logStream include - Remove strange comment - Fix javaThread include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20067/files - new: https://git.openjdk.org/jdk/pull/20067/files/cccffeda..ebf11542 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=07-08 Stats: 25 lines in 5 files changed: 0 ins; 8 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067 PR: https://git.openjdk.org/jdk/pull/20067 From aboldtch at openjdk.org Mon Jul 15 00:50:33 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Jul 2024 00:50:33 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 11:09:35 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/oops/instanceKlass.cpp line 1090: > >> 1088: >> 1089: // Step 2 >> 1090: // If we were to use wait() instead of waitUninterruptibly() then > > This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 > src/hotspot/share/oops/markWord.cpp line 27: > >> 25: #include "precompiled.hpp" >> 26: #include "oops/markWord.hpp" >> 27: #include "runtime/basicLock.inline.hpp" > > I don't think this include is needed (at least not by the changed code parts, I haven't checked existing code). It is probably included through some other transitive include. However all the metadata functions are now inlined. These are used here. `inline markWord BasicLock::displaced_header() const` and `inline void BasicLock::set_displaced_header(markWord header)` > src/hotspot/share/runtime/arguments.cpp line 1820: > >> 1818: warning("New lightweight locking not supported on this platform"); >> 1819: } >> 1820: if (UseObjectMonitorTable) { > > Uhm, wait a second. That list of platforms covers all existing platforms anyway, so the whole block could be removed? Or is there a deeper meaning here that I don't understand? Zero. Used as as start point for porting to new platforms. > src/hotspot/share/runtime/basicLock.cpp line 37: > >> 35: if (mon != nullptr) { >> 36: mon->print_on(st); >> 37: } > > I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. Yeah maybe it is unwanted. Not sure how we should treat these prints of the frames. My thinking was that there is something in the cache, print it. But maybe just treating it as some internal data, maybe print "monitor { }" or similar is better. > src/hotspot/share/runtime/basicLock.inline.hpp line 45: > >> 43: return reinterpret_cast(get_metadata()); >> 44: #else >> 45: // Other platforms does not make use of the cache yet, > > If it's not used, why does it matter to special case the code here? Because it is not used it there may be uninitialised values there. See https://github.com/openjdk/jdk/pull/20067#discussion_r1671959763 > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 28: > >> 26: >> 27: #include "classfile/vmSymbols.hpp" >> 28: #include "javaThread.inline.hpp" > > This include is incorrect (and my IDE says it's not needed). Correct, is should be `runtime/javaThread.inline.hpp`. Fixed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 31: > >> 29: #include "jfrfiles/jfrEventClasses.hpp" >> 30: #include "logging/log.hpp" >> 31: #include "logging/logStream.hpp" > > Include of logStream.hpp not needed? Yeah we removed all log streams. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: > >> 78: >> 79: ConcurrentTable* _table; >> 80: volatile size_t _table_count; > > Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. The current implementation is based on what we do for the StringTable and SymbolTable > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 88: > >> 86: >> 87: public: >> 88: Lookup(oop obj) : _obj(obj) {} > > Make explicit? Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 97: > >> 95: >> 96: bool equals(ObjectMonitor** value) { >> 97: // The entry is going to be removed soon. > > What does this comment mean? Not sure where it came from. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 112: > >> 110: >> 111: public: >> 112: LookupMonitor(ObjectMonitor* monitor) : _monitor(monitor) {} > > Make explicit? Done. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: > >> 157: static size_t min_log_size() { >> 158: // ~= log(AvgMonitorsPerThreadEstimate default) >> 159: return 10; > > Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. > > Or why not use AvgMonitorsPerThreadEstimate directly? Maybe that is resonable. I believe I had that at some point but it had to deal with how to handle extreme values of `AvgMonitorsPerThreadEstimate` as well as what to do when `AvgMonitorsPerThreadEstimate` was disabled `=0`. One 4 / 8 KB allocation seems harmless. But this was very arbitrary. This will probably be changed when/if the resizing of the table becomes more synchronised with deflation, allowing for shrinking the table. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 349: > >> 347: assert(LockingMode == LM_LIGHTWEIGHT, "must be"); >> 348: >> 349: if (try_read) { > > All the callers seem to pass try_read = true. Why do we have the branch at all? I'll clean this up. From experiments if was never better to use `insert_get` over a `get; insert_get`, even if we tried to be cleaver on when we skipped the initial get. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401: > >> 399: >> 400: if (inserted) { >> 401: // Hopefully the performance counters are allocated on distinct > > It doesn't look like the counters are on distinct cache lines (see objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to investigate it later? The comment here is a bit misplaced, IMO. It originates from https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.cpp#L1543 I think we just kept it and did not think more about it. Not sure what it is referring to. Maybe @dcubed-ojdk knows more, they originated from him (9 years old comment). > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477: > >> 475: if (obj->mark_acquire().has_monitor()) { >> 476: if (_length > 0 && _contended_oops[_length-1] == obj) { >> 477: // assert(VM_Version::supports_recursive_lightweight_locking(), "must be"); > > Uncomment or remove assert? Yeah not sure why it was ever uncommented. To me it seems like that the assert should be invariant. But will investigate. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 554: > >> 552: bool _no_safepoint; >> 553: union { >> 554: struct {} _dummy; > > Uhh ... Why does this need to be wrapped in a union and struct? A poor man's optional. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: > >> 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); >> 562: if (_no_safepoint) { >> 563: ::new (&_nsv) NoSafepointVerifier(); > > I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec > _no_safepoint_count(). I wanted to avoid having to add `NoSafepointVerifier` implementation details in the synchroniser code. I guess `ContinuationWrapper` already does this. Simply creating a `NoSafepointVerifier` when you expect no safepoint is more obvious to me, shows the intent better. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 748: > >> 746: } >> 747: >> 748: // Fast-locking does not use the 'lock' argument. > > I believe the comment is outdated. Removed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 969: > >> 967: >> 968: for (;;) { >> 969: // Fetch the monitor from the table > > Wrong intendation. Fixed. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1157: > >> 1155: // enter can block for safepoints; clear the unhandled object oop >> 1156: PauseNoSafepointVerifier pnsv(&nsv); >> 1157: object = nullptr; > > What is the point of that statement? object is not an out-arg (afaict), and not used subsequently. `CHECK_UNHANDLED_OOPS` + `-XX:+CheckUnhandledOops` https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/oops/oopsHierarchy.hpp#L53-L55 > src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: > >> 66: static void exit(oop object, JavaThread* current); >> 67: >> 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); > > My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* Yeah. The only effect is has is that you cannot reassign the variable. It was the style taken from [synchronizer.hpp](https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.hpp) where all `InflateCause` parameters are const. > src/hotspot/share/runtime/lockStack.inline.hpp line 232: > >> 230: oop obj = monitor->object_peek(); >> 231: assert(obj != nullptr, "must be alive"); >> 232: assert(monitor == LightweightSynchronizer::get_monitor_from_table(JavaThread::current(), obj), "must be exist in table"); > > "must be exist in table" -> "must exist in table" Done. > src/hotspot/share/runtime/objectMonitor.cpp line 56: > >> 54: #include "runtime/safepointMechanism.inline.hpp" >> 55: #include "runtime/sharedRuntime.hpp" >> 56: #include "runtime/synchronizer.hpp" > > This include is not used. Removed. > src/hotspot/share/runtime/objectMonitor.hpp line 193: > >> 191: ObjectWaiter* volatile _WaitSet; // LL of threads wait()ing on the monitor >> 192: volatile int _waiters; // number of waiting threads >> 193: private: > > You can now also remove the 'private:' here Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240569 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240591 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240598 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240629 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240633 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240644 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240655 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240709 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240664 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240684 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240695 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240712 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240735 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240747 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240787 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240807 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677240936 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241002 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241011 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241037 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241082 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241093 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241121 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1677241145 From dholmes at openjdk.org Mon Jul 15 01:56:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Jul 2024 01:56:53 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. @jaikiran there is a lot of unrelated refactoring and style changes here that obscures what the actual fix is. ------------- PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2176774069 From dholmes at openjdk.org Mon Jul 15 02:46:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Jul 2024 02:46:53 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:41:04 GMT, Kevin Walls wrote: > The jump is from the fact that nobody currently creates an empty CmdLine, to a ruling that nobody ever can in the future. No my point is either it is impossible to create an empty cmdline or else we should have a test that introduces one. If you cannot write such a test then it must be impossible. Hence we can assert that it cannot be empty. If worried about some future use then add a comment/check that would catch it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2227618338 From alanb at openjdk.org Mon Jul 15 07:09:50 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 07:09:50 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. I think the changes looks okay. It narrows to instrumenting a specific test class, thus removing all the side effects of the transformer code generating wrapper methods for JDK classes. The cleanups looks okay, test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 44: > 42: * @comment The test uses asmlib/Instrumentor.java which relies on ClassFile API PreviewFeature. > 43: * @run main/native/timeout=240 NativeMethodPrefixApp roleDriver > 44: * @comment The test uses a higher timeout to prevent test timeouts noted in JDK-6528548 Is /timeout=240 (and the comment) needed now. If I read the old issue correctly it was due to use a JDK mounted on a network file system. test/jdk/java/lang/instrument/libNativeMethodPrefix.c line 24: > 22: */ > 23: > 24: #include "jni.h" I assume this needs `#include `. ------------- PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2176976546 PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677385666 PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677383597 From jpai at openjdk.org Mon Jul 15 08:19:25 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 08:19:25 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - David's suggestion - remove cosmetic/style changes - no need to timeout=240 - include stdio.h in test native library - merge latest from master branch - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20154/files - new: https://git.openjdk.org/jdk/pull/20154/files/a16f5cdf..fa36314b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=00-01 Stats: 1599 lines in 104 files changed: 688 ins; 537 del; 374 mod Patch: https://git.openjdk.org/jdk/pull/20154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20154/head:pull/20154 PR: https://git.openjdk.org/jdk/pull/20154 From jpai at openjdk.org Mon Jul 15 08:19:26 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 08:19:26 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. Hello David, > @jaikiran there is a lot of unrelated refactoring and style changes here that obscures what the actual fix is. I've updated the PR to undo some of the cosmetic changes that were introduced to cleanup the code a bit. The updated state of the PR now just includes functional updates to the test to address the issue noted in the linked JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20154#issuecomment-2227935588 From jpai at openjdk.org Mon Jul 15 08:19:26 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 08:19:26 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v2] In-Reply-To: References: Message-ID: <5196RJrlIio4Tpc9JJOHsO3SXE3SS87s3SmZD_5RzH8=.0ee1079d-7fc1-458a-aa12-003e374af883@github.com> On Mon, 15 Jul 2024 07:00:12 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - David's suggestion - remove cosmetic/style changes >> - no need to timeout=240 >> - include stdio.h in test native library >> - merge latest from master branch >> - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out > > test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 44: > >> 42: * @comment The test uses asmlib/Instrumentor.java which relies on ClassFile API PreviewFeature. >> 43: * @run main/native/timeout=240 NativeMethodPrefixApp roleDriver >> 44: * @comment The test uses a higher timeout to prevent test timeouts noted in JDK-6528548 > > Is /timeout=240 (and the comment) needed now. If I read the old issue correctly it was due to use a JDK mounted on a network file system. In https://github.com/openjdk/jdk/pull/19495#discussion_r1625470816 we had considered removing the higher timeout from this test. But then decided to let it stay at that time. I think we don't need it anymore, not even when the test runs with `-Xcomp`. The recent runs in our CI for this test haven't shown the necessity of using this higher timeout. I have updated the PR to remove this. I plan to run additional tests in our CI to be sure that the removal of the timeout doesn't cause unexpected failures. > test/jdk/java/lang/instrument/libNativeMethodPrefix.c line 24: > >> 22: */ >> 23: >> 24: #include "jni.h" > > I assume this needs `#include `. Updated the PR to include this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677457539 PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677454337 From alanb at openjdk.org Mon Jul 15 08:38:51 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 08:38:51 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: <-4wsddqQYxYDI2ZMU7u-zqMDmqgM_IZuo8JEk_aOYjw=.9a15d0d4-f756-46c6-b2ac-390fdb04b1bf@github.com> On Mon, 15 Jul 2024 08:16:25 GMT, Jaikiran Pai wrote: > Hello David, > > > @jaikiran there is a lot of unrelated refactoring and style changes here that obscures what the actual fix is. > > I've updated the PR to undo some of the cosmetic changes that were introduced to cleanup the code a bit. The updated state of the PR now just includes functional updates to the test to address the issue noted in the linked JBS. Would it be possible to at least re-format the declaration of the "transform" method as it's very messy and hard to see what is declaration vs. body. The format that you had in the first iteration was helpful because it allowed us to clearly see what is in the declaration vs. body. I think I would do the same for the messy premain method but that can be cleanup/re-formatting for another day. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20154#issuecomment-2227969544 From jpai at openjdk.org Mon Jul 15 09:04:24 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 09:04:24 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v3] In-Reply-To: References: Message-ID: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: better formatting for transform() method of the test's agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20154/files - new: https://git.openjdk.org/jdk/pull/20154/files/fa36314b..1d303c90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20154/head:pull/20154 PR: https://git.openjdk.org/jdk/pull/20154 From jpai at openjdk.org Mon Jul 15 09:07:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 09:07:51 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: <-4wsddqQYxYDI2ZMU7u-zqMDmqgM_IZuo8JEk_aOYjw=.9a15d0d4-f756-46c6-b2ac-390fdb04b1bf@github.com> References: <-4wsddqQYxYDI2ZMU7u-zqMDmqgM_IZuo8JEk_aOYjw=.9a15d0d4-f756-46c6-b2ac-390fdb04b1bf@github.com> Message-ID: On Mon, 15 Jul 2024 08:36:01 GMT, Alan Bateman wrote: > Would it be possible to at least re-format the declaration of the "transform" method as it's very messy and hard to see what is declaration vs. body. Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20154#issuecomment-2228024140 From alanb at openjdk.org Mon Jul 15 09:26:52 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 09:26:52 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v3] In-Reply-To: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> References: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> Message-ID: On Mon, 15 Jul 2024 09:04:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? >> >> The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. >> >> Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. >> >> With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > better formatting for transform() method of the test's agent I don't have any other comments, it's good to have this test focus on just wrapping one native method. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2177240476 From dholmes at openjdk.org Mon Jul 15 10:10:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Jul 2024 10:10:52 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v3] In-Reply-To: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> References: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> Message-ID: On Mon, 15 Jul 2024 09:04:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? >> >> The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. >> >> Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. >> >> With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > better formatting for transform() method of the test's agent Okay. Still seems to be a lot more changes than needed for the key update, but so be it. Thanks test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 50: > 48: // It assumes that a specific non-native library method will call a specific > 49: // native method. The below may need to be updated based on library changes. > 50: static String goldenNativeMethodName = "fooBarNativeMethod"; The comment block above seems no longer applicable now this is not a library class method. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2177321848 PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677591632 From jpai at openjdk.org Mon Jul 15 10:21:23 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 10:21:23 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v4] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: update code comment in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20154/files - new: https://git.openjdk.org/jdk/pull/20154/files/1d303c90..7105565d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20154&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20154/head:pull/20154 PR: https://git.openjdk.org/jdk/pull/20154 From jpai at openjdk.org Mon Jul 15 10:21:23 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Jul 2024 10:21:23 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v3] In-Reply-To: References: <9E9nas-VC8oy9PuugZ1J1_PdDvpfzb4Mph3hN9HG-5g=.5fb23503-0aa2-4bea-8a8c-e86d952f568d@github.com> Message-ID: On Mon, 15 Jul 2024 10:05:24 GMT, David Holmes wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> better formatting for transform() method of the test's agent > > test/jdk/java/lang/instrument/NativeMethodPrefixApp.java line 50: > >> 48: // It assumes that a specific non-native library method will call a specific >> 49: // native method. The below may need to be updated based on library changes. >> 50: static String goldenNativeMethodName = "fooBarNativeMethod"; > > The comment block above seems no longer applicable now this is not a library class method. I've now updated the code comment to note what that constant is for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20154#discussion_r1677605240 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v9] In-Reply-To: References: Message-ID: > This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. > > Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. Maurizio Cimadamore 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 12 additional commits since the last revision: - Merge branch 'master' into restricted_jni - Address review comments - Add note on --illegal-native-access default value in the launcher help - Address review comment - Refine warning text for JNI method binding - Address review comments Improve warning for JNI methods, similar to what's described in JEP 472 Beef up tests - Address review comments - Fix another typo - Fix typo - Add more comments - ... and 2 more: https://git.openjdk.org/jdk/compare/2ced23fe...ff51ac6a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/789bdf48..ff51ac6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07-08 Stats: 168976 lines in 3271 files changed: 114666 ins; 38249 del; 16061 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8] In-Reply-To: References: Message-ID: <1f6cPvfYhyTzqeYoeA6uQi2WULB_Bq49AhF_RoEVWDQ=.9577a65e-b626-43fd-ab03-09783b978d94@github.com> On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. >> >> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2228489298 From ron.pressler at oracle.com Mon Jul 15 16:18:21 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 15 Jul 2024 16:18:21 +0000 Subject: [External] : Re: Proposal: Option to ignore non-existent -javaagent In-Reply-To: References: Message-ID: <145DDBA7-ABF4-407F-B40A-F6061148A353@oracle.com> > On 14 Jul 2024, at 16:56, Jaroslav Bachorik wrote: > > > The bottom line is that the clustering solution allows specifying JVM options and extra resources that will be distributed to all nodes. Hence, if you want to add an agent, you need to add the jvn options to point to the location where the agent jar (resource) will be placed. As you can expect, things can break and you end up killing your Spark pipeline instead of running without observably ???? So there?s a rather good solution to that: configuration @files. The JVM options passed could be simply `@config`, and when deploying the app you generate that file with or without a -javaagent option, depending on whether the deployment (or the machine) includes the agent or not. Now, I view a Java application as a tightly-coupled triple consisting of: 1. Code: A particular set of classes, some of which may be application code, some may be libraries and some may be agents. 2. Runtime: A particular jlinked runtime generated from a particular JDK version containing a particular set of JDK modules. The pre-jlinked runtime included in some JDK version is a special case of such a runtime. 3. Configuration: A particular set of options telling the runtime how to run the code. This includes configuring which JARs are named modules, which are in the unnamed module, and which are agents, as well as GC configuration, system properties etc.. The runtime configuration can be set in multiple ways: a set of command-line option in a startup script; a set of command-line options in an @file; a set of command-line options baked into the runtime with jlink; a set of JAR manifest attributes in an executable JAR?s manifest. Now, there should be no expectation that the application should continue to run when any one of these is changed on its own, without at least changing another. So, for example, changing the code may require changing the runtime (e.g. if a new JDK API unavailable in an old version is now used) or the configuration (e.g. if the program now requires more heap space). Changing the runtime may require changing the configuration, as configuration options are not backward compatible (e.g. memory footprint may change requiring a change to the heap size, some integrity requirement may be added requring adding a permission etc..). Changing the configuration may similarly require changing the runtime (e.g. if a selected GC is unavailable in an old runtime). In general, a working Java application is such a triplet where all three elements are tightly coupled. Because of that, we?re hesitant to add JDK capabilities that may give the wrong impression that the triplet is not tightly coupled. Perhaps the present issue is too narrow to discuss this broader subject, but we?ve often heard claims about the difficulty setting a configuration, sometimes alongside the incorrect expectation that the same configuration should work across multiple runtime versions. That is why we?re interested in collecting concrete examples to help us understand this challenge better, and we would appreciate if others could offer more details/examples. Anyway, do you think the @file solution could address the difficulty you encountered? > > However, I don?t understand the argument that running without agent can lead to subtle errors. Agents were always meant to be optional - the core application functionality should not really be dependent on the agent availability. But, obviously, I was wrong all this time. You are absolutely right that agents were originally intended for observability, but they?ve long since been used for functional purposes, too, and so can no longer be considered a pure observability feature. ? Ron From alanb at openjdk.org Mon Jul 15 16:28:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jul 2024 16:28:07 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates Message-ID: Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. Implementation: - Robustness improvements to not throw OOME when unparking a virtual thread. - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) - VirtualThread changes to reduce contention on timer queues when doing timed-park Tests: - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java - New test for ThreadMXBean.getLockedMonitor with synchronized native methods - Reimplement of JVMTI VThreadEvent test to improve reliability - Rename some tests to get consistent naming - Diagnostic output in several stress tests to help trace progress in the event of a timeout Testing: tier1-6 ------------- Commit messages: - Drop JLA updates for this update - Merge - Merge - Update copyright headers - Initial commit Changes: https://git.openjdk.org/jdk/pull/20143/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336254 Stats: 4116 lines in 42 files changed: 2528 ins; 1150 del; 438 mod Patch: https://git.openjdk.org/jdk/pull/20143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20143/head:pull/20143 PR: https://git.openjdk.org/jdk/pull/20143 From kbarrett at openjdk.org Mon Jul 15 16:36:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Jul 2024 16:36:57 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 05:34:24 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > USe os::snprintf in HotSpot Changes requested by kbarrett (Reviewer). src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > 30: #include /* for _MAx_PATH */ > 31: > 32: typedef unsigned long long UNSIGNED_JLONG; This change has nothing to do with _sprintf. Not sure why it's being made here. src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 54: > 52: > 53: typedef unsigned int juint; > 54: typedef unsigned long long julong; Similarly, his change has nothing to do with _sprintf. ------------- PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2178184310 PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1678105753 PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1678106243 From aturbanov at openjdk.org Mon Jul 15 17:07:55 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 15 Jul 2024 17:07:55 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright and jcheck error test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java line 598: > 596: * Print information about all threads in debuggee VM > 597: */ > 598: public void printThreadsInfo(VirtualMachine vm) { Suggestion: public void printThreadsInfo(VirtualMachine vm) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1678148019 From cjplummer at openjdk.org Mon Jul 15 18:08:26 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 15 Jul 2024 18:08:26 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v4] In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Remove extra space. Cleanup header println() in printThreadsInfo() since it is now general purpose and not just used when killing debuggee. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20088/files - new: https://git.openjdk.org/jdk/pull/20088/files/3c9b88d6..bb926b44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20088/head:pull/20088 PR: https://git.openjdk.org/jdk/pull/20088 From amenkov at openjdk.org Mon Jul 15 19:09:52 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Jul 2024 19:09:52 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v4] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Mon, 15 Jul 2024 18:08:26 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra space. Cleanup header println() in printThreadsInfo() since it is now general purpose and not just used when killing debuggee. Marked as reviewed by amenkov (Reviewer). Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2178453387 PR Review: https://git.openjdk.org/jdk/pull/20088#pullrequestreview-2178456664 From amenkov at openjdk.org Mon Jul 15 19:56:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Jul 2024 19:56:13 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v3] In-Reply-To: References: Message-ID: > The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes > > testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Chris feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19780/files - new: https://git.openjdk.org/jdk/pull/19780/files/be66602d..f075a001 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19780&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19780&range=01-02 Stats: 53 lines in 2 files changed: 28 ins; 6 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/19780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19780/head:pull/19780 PR: https://git.openjdk.org/jdk/pull/19780 From amenkov at openjdk.org Mon Jul 15 19:58:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Jul 2024 19:58:54 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v2] In-Reply-To: References: Message-ID: <9mWwYO8KIeiI9HM-mbiW1AUr7pV0zeeu7oTu0szPePg=.82c3f7d2-5342-4902-948b-4635ab0665fb@github.com> On Sat, 13 Jul 2024 01:45:50 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 79: >> >>> 77: // Value length exceeds 1K. >>> 78: Test withLongValue() { >>> 79: flagValue = generateValue(1024 + 1); >> >> Shouldn't we also be testing exactly 1024 and expect it to work? > > good question! > tried to make it 1024 and it does not work! > Windows VirtualMachineImpl has one more issue - it uses 1024 char buffers, but it should be (1024 + 1) as AttachListener does (1 extra char to 0-terminator), so maximum argument size on windows is 1023. > Will fix it. Fixed the issue, also renamed ` jstring_to_cstring` argument to make it clear that buffer size is expected and updated callers to use `sizeof`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1678321643 From amenkov at openjdk.org Mon Jul 15 20:11:52 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Jul 2024 20:11:52 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v3] In-Reply-To: References: Message-ID: <-9i-Bn_ZLI8IEExT8qXI-HrNVHYvLdPIOaZi4nzvU0c=.5ff289c1-3f7c-42ea-904a-3b1508a1b0d9@github.com> On Sat, 13 Jul 2024 06:21:45 GMT, Serguei Spitsyn wrote: >> Currently Attach operations have restriction for argument size, so setFlag() is expected to fail for long values. >> This fix adds AttachOperationFailedException for the case on windows, linux/bsd/aix implementations throw generic IOException. >> (There is [JDK-8334168](https://bugs.openjdk.org/browse/JDK-8334168) to throw AttachOperationFailedException instead of IOException if an argument is too long on other platforms) > > Not sure, you've answered my question. Let me ask it differently. > Here I do not care about other exceptions on other platforms. > The `setFlag()` can catch an `IOException` at the line 126 and return false in that case. The `run()` method at the line 94 is swallowing the `false` value as there is no `else` statement. So, we just ignore the `IOException` and do not test anything. > My question is: Why don't we throw a `RuntimeException` in the case the `setFlag()` returned `false`? Because `vm.setFlag` may (and should) throw exception if bad argument is specified. This is what the issue about - on Windows `vm.setFlag` with long argument did not throw exception, but truncated the argument, and successfully executed the command with truncated argument value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19780#discussion_r1678334111 From cjplummer at openjdk.org Mon Jul 15 20:29:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 15 Jul 2024 20:29:55 GMT Subject: RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v4] In-Reply-To: References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Mon, 15 Jul 2024 18:08:26 GMT, Chris Plummer wrote: >> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra space. Cleanup header println() in printThreadsInfo() since it is now general purpose and not just used when killing debuggee. Thanks for the reviews from Kevin, Alex, and Serguei and input from David, Dan, and Andrey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2229339966 From cjplummer at openjdk.org Mon Jul 15 20:29:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 15 Jul 2024 20:29:55 GMT Subject: Integrated: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent In-Reply-To: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> References: <1UZOiOU20TWiPqv55rkwTTKqyRBQCp8Ak-FRndqNSFE=.73e29dd7-0f62-45f5-8f59-5ebad28f4d1f@github.com> Message-ID: On Tue, 9 Jul 2024 04:43:59 GMT, Chris Plummer wrote: > The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so only thread2 is suspended. It then does a vm.suspend(), which suspends all threads and bumps the suspendCount of thread2 up to 2. It then does an eventSet.resume(), which decrements the thread2 suspendCount to 1, so now all threads are suspended with a suspendCount of 1. thread2 is then resumed and we expect to hit the next thread2 breakpoint. The problem is that thread2 can't hit the breakpoint until the main thread has proceeded far enough, and if the vm.suspend() that suspended the main thread happens too quickly, it won't have proceeded far enough, so thread2 never hits the breakpoint. > > Essentially we need a vm.resume() to allow the main thread to run, but we need to do it in a way that does nullify part of what the test is testing for. So in order to allow the vm.resume() but not subvert the intent of the test, we first do a thread2.suspend() so the vm.resume() won't resume thread2. > > Testing in progress: tier1 and tier5 svc testing This pull request has now been integrated. Changeset: c8a95a76 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/c8a95a763c169b94c5ba07d2c6fbdf99ba3b9e3b Stats: 39 lines in 3 files changed: 26 ins; 6 del; 7 mod 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent Reviewed-by: amenkov, kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/20088 From dholmes at openjdk.org Mon Jul 15 21:25:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Jul 2024 21:25:52 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v4] In-Reply-To: References: Message-ID: <3pfonT1DhrUA5VxUgRn-7FGMPNtCZKwWHX7_ywTFBQ8=.0dbb0672-17da-44e0-974e-57900b88d2d2@github.com> On Mon, 15 Jul 2024 10:21:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? >> >> The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. >> >> Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. >> >> With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update code comment in test Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2178701028 From cjplummer at openjdk.org Mon Jul 15 21:57:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 15 Jul 2024 21:57:52 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:56:13 GMT, Alex Menkov wrote: >> The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes >> >> testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Chris feedback Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19780#pullrequestreview-2178743360 From sspitsyn at openjdk.org Tue Jul 16 00:07:52 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Jul 2024 00:07:52 GMT Subject: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 14:47:21 GMT, Markus Gr?nlund wrote: > Greetings, > > Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds assertions about the JFR bit tag state machine. > > Testing: jdk_jfr, stress testing > > Thanks > Markus src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp line 47: > 45: #define RESTORE_ID(k) JfrTraceId::restore(k); > 46: > 47: static constexpr const uint16_t cleared_epoch_bits = 512 | 256; Q: Could the `EPOCH_CLEARED_BITS` be used instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20171#discussion_r1678533638 From sspitsyn at openjdk.org Tue Jul 16 00:43:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Jul 2024 00:43:54 GMT Subject: RFR: 8334169: Long arguments of attach operation are silently truncated on Windows [v3] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:56:13 GMT, Alex Menkov wrote: >> The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes >> >> testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Chris feedback Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19780#pullrequestreview-2178962987 From sspitsyn at openjdk.org Tue Jul 16 02:18:52 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 16 Jul 2024 02:18:52 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v4] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 10:21:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? >> >> The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. >> >> Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. >> >> With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update code comment in test Nice test update making it more reliable and readable. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20154#pullrequestreview-2179064111 From jpai at openjdk.org Tue Jul 16 03:39:51 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Jul 2024 03:39:51 GMT Subject: RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out [v4] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 10:21:23 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? >> >> The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. >> >> Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. >> >> With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > update code comment in test Thank you all for the reviews and inputs. I'll go ahead with the integration in a few hours from now, once the CI test jobs I trigger for this, complete. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20154#issuecomment-2229945315 From dholmes at openjdk.org Tue Jul 16 06:00:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Jul 2024 06:00:51 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 src/java.base/share/classes/java/lang/VirtualThread.java line 273: > 271: // current thread is a ForkJoinWorkerThread so the task will be pushed > 272: // to the local queue. For other schedulers, it avoids deadlock that > 273: // would arise due to platform and virtual threads contenting for a s/contenting/contending/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1678800192 From jwaters at openjdk.org Tue Jul 16 08:54:54 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Jul 2024 08:54:54 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> USe os::snprintf in HotSpot > > src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: > >> 30: #include /* for _MAx_PATH */ >> 31: >> 32: typedef unsigned long long UNSIGNED_JLONG; > > This change has nothing to do with _sprintf. Not sure why it's being made here. It was a small change, so I thought I could make it out of convenience. I'll switch it out to a separate changeset ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1679012119 From jwaters at openjdk.org Tue Jul 16 08:59:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 16 Jul 2024 08:59:20 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: > snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 > > Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert Standard Integer type rewrite ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20153/files - new: https://git.openjdk.org/jdk/pull/20153/files/1bd6bc09..a0477b8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153 PR: https://git.openjdk.org/jdk/pull/20153 From mgronlun at openjdk.org Tue Jul 16 10:49:51 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 16 Jul 2024 10:49:51 GMT Subject: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: <55O85lCa4MwD26yQDhfO2f2hnL8iKbsMtxPaYfInRTw=.525aa1e7-491c-4d10-b42a-19e5eb4df576@github.com> On Tue, 16 Jul 2024 00:05:36 GMT, Serguei Spitsyn wrote: >> Greetings, >> >> Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds assertions about the JFR bit tag state machine. >> >> Testing: jdk_jfr, stress testing >> >> Thanks >> Markus > > src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp line 47: > >> 45: #define RESTORE_ID(k) JfrTraceId::restore(k); >> 46: >> 47: static constexpr const uint16_t cleared_epoch_bits = 512 | 256; > > Q: Could the `EPOCH_CLEARED_BITS` be used instead? No. because I want to avoid dragging in all of the definitions in jfrTraceIdMarcros.hpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20171#discussion_r1679179786 From kbarrett at openjdk.org Tue Jul 16 11:49:54 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Jul 2024 11:49:54 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2180004090 From kbarrett at openjdk.org Tue Jul 16 11:49:55 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Jul 2024 11:49:55 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:52:01 GMT, Julian Waters wrote: >> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32: >> >>> 30: #include /* for _MAx_PATH */ >>> 31: >>> 32: typedef unsigned long long UNSIGNED_JLONG; >> >> This change has nothing to do with _sprintf. Not sure why it's being made here. > > It was a small change, so I thought I could make it out of convenience. I'll switch it out to a separate changeset There are lots of uses of those type names. If they are going to be cleaned up, I'd prefer that get done as as separate task, so I don't need to think about whether it's okay to do so while in the context of this change. I don't know if __int64 == long long (probably is), but I'm pretty sure I remember seeing a comment on some use of __int32 suggesting it was not the same as what someone expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20153#discussion_r1679248371 From djelinski at openjdk.org Tue Jul 16 12:27:51 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 16 Jul 2024 12:27:51 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2180081756 From rkennke at openjdk.org Tue Jul 16 12:46:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 16 Jul 2024 12:46:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include Another review pass by me. It looks to me like the cache lookup can be improved, see comments below. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 323: > 321: ldr(t1, Address(t3_t)); > 322: cmp(obj, t1); > 323: br(Assembler::EQ, monitor_found); I think the loop could be optimized a bit, if we start with the (cache_address) - 1 in t3, then increment t3 at the start of the loop, and let the success-case fall-through and only branch back to loop-start or to failure-path. Something like: bind(loop); increment(t3_t, in_bytes(OMCache::oop_to_oop_difference())); ldr(t1, Address(t3_t)); cbnz(t1, loop); cmp(obj, t1); br(Assembler::NE, loop); // Success Advantage would be that we have no forward-branch in the fast/expected case. CPU static branch prediction tends to not like that. I'm not sure if if makes a difference, though. Also, if you do that, then the unrolled loop also needs corresponding adjustment. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: > 672: > 673: // Search for obj in cache. > 674: bind(loop); Same loop transformation would be possible here. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 776: > 774: movl(top, Address(thread, JavaThread::lock_stack_top_offset())); > 775: > 776: if (!UseObjectMonitorTable) { Why is the mark loaded here in the !UOMT case, but later in the +UOMT case? ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2179942149 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679210139 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679313050 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679315158 From rkennke at openjdk.org Tue Jul 16 12:46:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 16 Jul 2024 12:46:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> References: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com> Message-ID: On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 776: > >> 774: movl(top, Address(thread, JavaThread::lock_stack_top_offset())); >> 775: >> 776: if (!UseObjectMonitorTable) { > > Why is the mark loaded here in the !UOMT case, but later in the +UOMT case? Ah I see, it is because we don't have enough registers. Right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1679316824 From clanger at openjdk.org Tue Jul 16 12:50:54 2024 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 16 Jul 2024 12:50:54 GMT Subject: Integrated: 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 In-Reply-To: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> References: <7pVh06-nrkg2CMr9iU7ZeRDXT7KLUWavUAPNmYN7AIU=.18b29a62-f367-4afa-b3f9-fdafec0f04d0@github.com> Message-ID: On Wed, 10 Jul 2024 09:14:11 GMT, Christoph Langer wrote: > The change of JDK-8294960 has brought an increase of required metaspace for this test on AIX which seems to go beyond 23m in most cases. So I propose another slight increment. > > Why AIX needs more metaspace compared to other platforms is probably a different topic. This pull request has now been integrated. Changeset: 419cc462 Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/419cc4624891e5775847f8acaf92fa8c42a9719c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960 Reviewed-by: mbaesken, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/20106 From amenkov at openjdk.org Tue Jul 16 18:13:59 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 16 Jul 2024 18:13:59 GMT Subject: Integrated: 8334169: Long arguments of attach operation are silently truncated on Windows In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 01:50:30 GMT, Alex Menkov wrote: > The change fixes a bug in Attach API implementation on Windows when argument(s) are longer than 1023 bytes > > testing: test/hotspot/jtreg/serviceability/attach, test/jdk/com/sun/tools/attach on Oracle supported platforms This pull request has now been integrated. Changeset: a60608e7 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/a60608e7a35aeeed57bcce641d4957de1e4b4def Stats: 213 lines in 2 files changed: 198 ins; 1 del; 14 mod 8334169: Long arguments of attach operation are silently truncated on Windows Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/19780 From cjplummer at openjdk.org Tue Jul 16 19:05:04 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 16 Jul 2024 19:05:04 GMT Subject: RFR: 8336420: Added JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list Message-ID: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> The following two Xcomp problem list entries need were removed: vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java 8205957 generic-all vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java 8205957 linux-x64,windows-x64 Each of these tests now has #id0 and #logging versions, and they are failing, so they need to be problem listed. ------------- Commit messages: - update setfmodw001 to general-all since it failed on linux-aarch65. - add tests failing due to 8205957 Changes: https://git.openjdk.org/jdk/pull/20201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336420 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20201/head:pull/20201 PR: https://git.openjdk.org/jdk/pull/20201 From dcubed at openjdk.org Tue Jul 16 20:31:51 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 16 Jul 2024 20:31:51 GMT Subject: RFR: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list In-Reply-To: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> References: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> Message-ID: On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java 8205957 linux-x64,windows-x64 > > Each of these tests now has #id0 and #logging versions, and they are failing, so they need to be problem listed. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20201#pullrequestreview-2181250160 From cjplummer at openjdk.org Tue Jul 16 23:29:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 16 Jul 2024 23:29:54 GMT Subject: RFR: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list In-Reply-To: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> References: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> Message-ID: On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java 8205957 linux-x64,windows-x64 > > Each of these tests now has #id0 and #logging versions, and they are failing, so they need to be problem listed. Thanks for the review, Dan! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20201#issuecomment-2231978664 From cjplummer at openjdk.org Tue Jul 16 23:29:54 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 16 Jul 2024 23:29:54 GMT Subject: Integrated: 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list In-Reply-To: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> References: <4JtMGkxpCbS3Qd-kX1376A3cV62xnlfcB_7z9SpEAGQ=.43d5e99c-0983-4238-bc88-2ab1859b7a7e@github.com> Message-ID: On Tue, 16 Jul 2024 18:56:53 GMT, Chris Plummer wrote: > The following two Xcomp problem list entries were removed: > > vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java 8205957 generic-all > vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java 8205957 linux-x64,windows-x64 > > Each of these tests now has #id0 and #logging versions, and they are failing, so they need to be problem listed. This pull request has now been integrated. Changeset: f3e7063e Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/f3e7063e26cefb6643e4150b7fcbdc9a1fdaebed Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/20201 From kvn at openjdk.org Wed Jul 17 03:42:07 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 03:42:07 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI Message-ID: Citing David Holmes from bug report: "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. I ran 2 rounds of testing: First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). Second round of testing with JVMTI in VM: tier1-4 ------------- Commit messages: - 8335921: Fix HotSpot VM build without JVMTI Changes: https://git.openjdk.org/jdk/pull/20209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335921 Stats: 20 lines in 8 files changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/20209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20209/head:pull/20209 PR: https://git.openjdk.org/jdk/pull/20209 From dholmes at openjdk.org Wed Jul 17 04:59:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 04:59:51 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 This seems reasonable to me. It highlights the problem we have with optional components in that you either have to work things so that semantically we have a do-nothing implementation of that component, or else you have to put the guards around every piece of code that would normally interact with it. Thanks. src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp line 35: > 33: JfrJvmtiAgent(); > 34: ~JfrJvmtiAgent(); > 35: static bool create() NOT_JVMTI_RETURN_(true); It initially seemed odd to return `true` here, but looking through the JFR code that interacts with the Agent it seems the right way to view this is that without JVMTI we have a no-op agent. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20209#pullrequestreview-2181875380 PR Review Comment: https://git.openjdk.org/jdk/pull/20209#discussion_r1680403451 From dholmes at openjdk.org Wed Jul 17 05:21:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:21:52 GMT Subject: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170 >> >> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?) > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert Standard Integer type rewrite Okay for HotSpot, jdk.hotspot.agent, jdk.jdwp.agent and jdk.management. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2181900237 From kvn at openjdk.org Wed Jul 17 05:41:52 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 05:41:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <7TC1wAE-NN6af0pg5dEJxInkJxhIU0mq0RJ8NDK_c3U=.84572ae7-b0d0-44e4-89dc-df7bd73a58ea@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Thank you, David, for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2232459481 From kvn at openjdk.org Wed Jul 17 05:41:53 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 05:41:53 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> References: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> Message-ID: On Wed, 17 Jul 2024 04:52:35 GMT, David Holmes wrote: >> Citing David Holmes from bug report: >> "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." >> >> I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. >> >> Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. >> >> A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. >> I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. >> >> I ran 2 rounds of testing: >> >> First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). >> >> Second round of testing with JVMTI in VM: tier1-4 > > src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp line 35: > >> 33: JfrJvmtiAgent(); >> 34: ~JfrJvmtiAgent(); >> 35: static bool create() NOT_JVMTI_RETURN_(true); > > It initially seemed odd to return `true` here, but looking through the JFR code that interacts with the Agent it seems the right way to view this is that without JVMTI we have a no-op agent. Right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20209#discussion_r1680433885 From jpai at openjdk.org Wed Jul 17 06:17:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 17 Jul 2024 06:17:01 GMT Subject: Integrated: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 09:22:54 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to fix the test timeout reported in https://bugs.openjdk.org/browse/JDK-8334167? > > The JBS issue has comments which explains what causes the timeout. The commit in this PR addresses those issues by updating the test specific `ClassFileTransformer` to only instrument application specific class instead of all (core) classes. The test was introduced several years back to verify the feature introduced in https://bugs.openjdk.org/browse/JDK-6263319. As such, the proposed changes in this PR continue to test that feature - we now merely use application specific class' native method to verify the semantics of that feature. > > Additional cleanups have been done in the test to make sure that if any exception does occur in the ClassFileTransformer then it does get recorded and that then causes the test to fail. > > With this change, I have run tier1 through tier6 and the test passes. Additionally, without this change I've run the test with a test repeat of 100 with virtual threads enabled and the test hangs occasionally (as expected). With this proposed fix, I have then run the test with virtual threads, around 300 times and it hasn't failed or hung in any of those instances. This pull request has now been integrated. Changeset: 3babffd4 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/3babffd4002be62f9f75a1a773c9561804612fad Stats: 151 lines in 3 files changed: 80 ins; 47 del; 24 mod 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Reviewed-by: dholmes, sspitsyn, alanb ------------- PR: https://git.openjdk.org/jdk/pull/20154 From dholmes at openjdk.org Wed Jul 17 06:37:57 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:37:57 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/basicLock.hpp line 44: > 42: // a sentinel zero value indicating a recursive stack-lock. > 43: // * For LM_LIGHTWEIGHT > 44: // Used as a cache the ObjectMonitor* used when locking. Must either The first sentence doesn't read correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680492976 From dholmes at openjdk.org Wed Jul 17 06:42:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:42:53 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/basicLock.hpp line 46: > 44: // Used as a cache the ObjectMonitor* used when locking. Must either > 45: // be nullptr or the ObjectMonitor* used when locking. > 46: volatile uintptr_t _metadata; The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680496495 From dholmes at openjdk.org Wed Jul 17 06:42:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:42:54 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> References: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> Message-ID: On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/basicLock.hpp line 46: > >> 44: // Used as a cache the ObjectMonitor* used when locking. Must either >> 45: // be nullptr or the ObjectMonitor* used when locking. >> 46: volatile uintptr_t _metadata; > > The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? I should have read ahead. I see you do keep the setters/getters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680497748 From dholmes at openjdk.org Wed Jul 17 06:46:00 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:46:00 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/deoptimization.cpp line 1641: > 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); > 1640: if (LockingMode == LM_LEGACY) { > 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680500696 From dholmes at openjdk.org Wed Jul 17 06:50:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 06:50:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1FImJurji3MUi1rauLpFYqETg45LmnlxLrRijzXBukg=.7125982a-3507-4711-922e-2c7c9706d87c@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 60: > 58: > 59: // ConcurrentHashTable storing links from objects to ObjectMonitors > 60: class ObjectMonitorWorld : public CHeapObj { OMWorld describes the project not the hashtable, this should be called ObjectMonitorTable or some such. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: > 60: class ObjectMonitorWorld : public CHeapObj { > 61: struct Config { > 62: using Value = ObjectMonitor*; Does this alias really help? We don't state the type that many times and it looks odd to end up with a mix of `Value` and `ObjectMonitor*` in the same code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680508685 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680508801 From dholmes at openjdk.org Wed Jul 17 07:02:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 07:02:55 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: > 100: assert(*value != nullptr, "must be"); > 101: return (*value)->object_is_cleared(); > 102: } The `is_dead` functions seem oddly placed given they do not relate to the object stored in the wrapper. Why are they here? And what is the difference between `object_is_cleared` and `object_is_dead` (as used by `LookupMonitor`) ? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: > 103: }; > 104: > 105: class LookupMonitor : public StackObj { I'm not understanding why we need this little wrapper class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680526331 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1680526868 From shade at openjdk.org Wed Jul 17 08:55:51 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 08:55:51 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Looks okay. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20209#pullrequestreview-2182317512 From shade at openjdk.org Wed Jul 17 08:58:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 08:58:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> References: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> Message-ID: On Wed, 17 Jul 2024 04:57:38 GMT, David Holmes wrote: > It highlights the problem we have with optional components in that you either have to work things so that semantically we have a do-nothing implementation of that component, or else you have to put the guards around every piece of code that would normally interact with it. At some point a few years ago I explored a private testing pipeline that built VM with different combination of options. It worked, but there were so many issues that cropped up continuously that I scratched that off as the lost cause. I gave up even on building Minimal. Fixing the particular build configurations every once in a while -- like this PR -- seems to be a pragmatic compromise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2232790329 From mgronlun at openjdk.org Wed Jul 17 11:19:56 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 17 Jul 2024 11:19:56 GMT Subject: Integrated: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 14:47:21 GMT, Markus Gr?nlund wrote: > Greetings, > > Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds assertions about the JFR bit tag state machine. > > Testing: jdk_jfr, stress testing > > Thanks > Markus This pull request has now been integrated. Changeset: 67979eb0 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce Stats: 34 lines in 7 files changed: 17 ins; 3 del; 14 mod 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/20171 From mgronlun at openjdk.org Wed Jul 17 11:29:06 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 17 Jul 2024 11:29:06 GMT Subject: [jdk23] RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Message-ID: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant ------------- Commit messages: - Backport 67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce Changes: https://git.openjdk.org/jdk/pull/20217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334781 Stats: 34 lines in 7 files changed: 17 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20217/head:pull/20217 PR: https://git.openjdk.org/jdk/pull/20217 From egahlin at openjdk.org Wed Jul 17 11:33:51 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 17 Jul 2024 11:33:51 GMT Subject: [jdk23] RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 11:21:04 GMT, Markus Gr?nlund wrote: > 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20217#pullrequestreview-2182648511 From mgronlun at openjdk.org Wed Jul 17 12:18:57 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 17 Jul 2024 12:18:57 GMT Subject: [jdk23] Integrated: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 11:21:04 GMT, Markus Gr?nlund wrote: > 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant This pull request has now been integrated. Changeset: 88775f95 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/88775f95f2b25323a75c5acad43ec9131c5e80fe Stats: 34 lines in 7 files changed: 17 ins; 3 del; 14 mod 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin Backport-of: 67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce ------------- PR: https://git.openjdk.org/jdk/pull/20217 From szaldana at openjdk.org Wed Jul 17 13:52:05 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 17 Jul 2024 13:52:05 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Message-ID: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Hi all, This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. This PR addresses the following diagnostic commands: - [x] Compiler.perfmap - [x] GC.heap_dump - [x] System.dump_map - [x] Thread.dump_to_file - [x] VM.cds Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, filename (Optional) Name of the file to which the flight recording data is written when the recording is stopped. If no filename is given, a filename is generated from the PID and the current date and is placed in the directory where the process was started. The filename may also be a directory in which case, the filename is generated from the PID and the current date in the specified directory. (STRING, no default value) Note: If a filename is given, '%p' in the filename will be replaced by the PID, and '%t' will be replaced by the time in 'yyyy_MM_dd_HH_mm_ss' format. Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. Testing: - [x] Added test case passes. - [x] Modified existing VM.cds tests to also check for `%p` filenames. Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). Cheers, Sonia ------------- Commit messages: - 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Changes: https://git.openjdk.org/jdk/pull/20198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334492 Stats: 130 lines in 5 files changed: 116 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Wed Jul 17 14:02:31 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 17 Jul 2024 14:02:31 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Updating copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/ee46dab5..eea54f6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From stuefe at openjdk.org Wed Jul 17 14:24:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Jul 2024 14:24:54 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> On Wed, 17 Jul 2024 14:02:31 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating copyright headers First cursory review. That is a useful feature - In all cases: please, in case of an error, don't THROW, don't do `warning`. Instead, just print to the `output()` of the DCmd. You want an error to appear to the user of the dcmd - so, to stdout or stderr of the jcmd process issuing the command. Not an exception in the target JVM process, nor a warning in the target JVM stderr stream - Can you give us a variant of `Arguments::copy_expand_pid` that receives a zero-terminated const char* as input so that we can avoid having to pass in the length of the input each time? - when passing in output buffers to functions, try to use sizeof(buffer) instead of repeating the buffer size. Then, one can change the size of the buffer array without having to modify using calls (but aware: pitfall, sizeof(char[]) vs sizeof(char*)) src/hotspot/share/code/codeCache.cpp line 1796: > 1794: // Perf expects to find the map file at /tmp/perf-.map > 1795: // if the file name is not specified. > 1796: char fname[JVM_MAXPATHLEN]; Good to see this gone, the old code implicitly relied on: max pid len -2147483647 = 11 chars, + length of "/tmp/perf-.map" not overflowing 32, which cuts a bit close to the bone. src/hotspot/share/code/codeCache.cpp line 1800: > 1798: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", > 1799: os::current_process_id()); > 1800: } Arguably one could just do constexpr char[] filename_default = "/tmp/perf-%p.map"; Arguments::copy_expand_pid(filename == nullptr ? filename_default : filename, .....); src/hotspot/share/services/diagnosticCommand.cpp line 525: > 523: stringStream msg; > 524: msg.print("Invalid file path name specified: %s", _filename.value()); > 525: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), msg.base()); Why throw? Why not just print an error message to the output() stream and return? src/hotspot/share/services/diagnosticCommand.cpp line 1059: > 1057: fileh = java_lang_String::create_from_str(fname, CHECK); > 1058: } else { > 1059: warning("Invalid file path name specified, fall back to default name"); `warning` prints a warning to the stdout of the JVM process. You don't want that; you want a warning to the issuer of the dcmd, which is another - possibly even remote - process. Write errors to `output()`, instead. src/hotspot/share/services/diagnosticCommand.cpp line 1138: > 1136: stringStream msg; > 1137: msg.print("Invalid file path name specified: %s", _filepath.value()); > 1138: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), msg.base()); write to output() and return instead of throwing ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2183023385 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681109673 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681115247 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681118969 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681124783 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681125914 From stuefe at openjdk.org Wed Jul 17 14:24:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 17 Jul 2024 14:24:54 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> Message-ID: On Wed, 17 Jul 2024 14:02:01 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating copyright headers > > src/hotspot/share/code/codeCache.cpp line 1800: > >> 1798: jio_snprintf(fname, sizeof(fname), "/tmp/perf-%d.map", >> 1799: os::current_process_id()); >> 1800: } > > Arguably one could just do > > constexpr char[] filename_default = "/tmp/perf-%p.map"; > Arguments::copy_expand_pid(filename == nullptr ? filename_default : filename, .....); This pattern can be followed in all cases where we have default filenames ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681149193 From alanb at openjdk.org Wed Jul 17 16:30:52 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Jul 2024 16:30:52 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v2] In-Reply-To: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> Message-ID: <70ENucevFdhpARyQni4sy3uUh93-FFQz038hJYswZqE=.76860fb0-94a3-473e-bb3c-9c9733a850b2@github.com> On Wed, 17 Jul 2024 14:07:55 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating copyright headers > > src/hotspot/share/services/diagnosticCommand.cpp line 1138: > >> 1136: stringStream msg; >> 1137: msg.print("Invalid file path name specified: %s", _filepath.value()); >> 1138: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), msg.base()); > > write to output() and return instead of throwing Yes, the error needs to be written the stream so that it is printed by the tool (at the end other of the pipe). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681352690 From kvn at openjdk.org Wed Jul 17 16:36:52 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 16:36:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <0ta5_zgRm_HBLh0jhqZm807Qe5sYsSb3rNTEF9j2p2Q=.a303a8ac-b957-4727-832a-36d834d165a4@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Thank you, Aleksey, for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2233729056 From kvn at openjdk.org Wed Jul 17 18:48:35 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 18:48:35 GMT Subject: Integrated: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 This pull request has now been integrated. Changeset: bcb5e695 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/bcb5e69505f6cc8a4f323924cd2c58e630595fc0 Stats: 20 lines in 8 files changed: 7 ins; 0 del; 13 mod 8335921: Fix HotSpot VM build without JVMTI Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/20209 From szaldana at openjdk.org Wed Jul 17 19:59:10 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 17 Jul 2024 19:59:10 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v3] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Updates based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/eea54f6d..3bb774d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=01-02 Stats: 35 lines in 4 files changed: 0 ins; 12 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From lmesnik at openjdk.org Thu Jul 18 00:49:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 00:49:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v3] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <-1Ejx0t2f_Q0Hl9nKsil_C2hweWnB9pTdvbID9_OMtQ=.fa91c0d0-fb81-4e12-b946-a9cdc1125c6c@github.com> On Wed, 17 Jul 2024 19:59:10 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on feedback Changes requested by lmesnik (Reviewer). src/hotspot/share/code/codeCache.cpp line 1791: > 1789: > 1790: #ifdef LINUX > 1791: void CodeCache::write_perf_map(const char* filename, outputStream* out) { I don't think that it is a right place ti expand arguments here. I think it is more consistent to do it in diagnosticCommand.cpp for any jcmd command. So this logic might be the same for any _filename processing. Moreover it would be better be add 'FileArgument' like 'MemorySizeArgument' that correctly parse patterns like %p for all file arguments, used be all commands and be extensible for new macroses if needed. test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java line 32: > 30: * @modules java.base/jdk.internal.misc > 31: * java.management > 32: * @run main/othervm TestJcmdPIDSubstitution Why othervm is needed here? I suggest to add driver mode instead. test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java line 59: > 57: do { > 58: path = Paths.get("myfile%d".formatted(pid)); > 59: } while(Files.exists(path)); Why this do/while loop is needed? Each test should have it's own empty scratch directory. ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2184333180 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681931084 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681921063 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1681920781 From lmesnik at openjdk.org Thu Jul 18 00:57:37 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 00:57:37 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v2] In-Reply-To: <5w-lZYTr6ZVThJZFscOqVevqSvwvnMXcIB49TuuZIUM=.2b93bc7b-0d7c-4ffd-9811-2846f0502999@github.com> References: <5w-lZYTr6ZVThJZFscOqVevqSvwvnMXcIB49TuuZIUM=.2b93bc7b-0d7c-4ffd-9811-2846f0502999@github.com> Message-ID: <1pMETIlZ-MIOSLrkafaGryt6HDyPu9rroNPR6SvCWRU=.2d0e0caf-6e17-4117-a550-4cfdafd47c33@github.com> On Fri, 12 Jul 2024 09:16:05 GMT, Kevin Walls wrote: >> Short version: >> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" >> >> Make additional typo fixes and tidyups while here, it's just shocking. >> >> TestDescription.java contains the test definition, so the "requires" goes there, with a comment. >> >> Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > formatting Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20146#pullrequestreview-2184355125 From lmesnik at openjdk.org Thu Jul 18 01:05:36 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 01:05:36 GMT Subject: RFR: 8313235: TestClhsdbJstackLock.java failed with '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class for LingeredAppWithLock\)$' missing from stdout/stderr In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 22:30:52 GMT, Chris Plummer wrote: > Once the main thread has detected that the spawned thread is in the BLOCKED state, the spawned thread's LingeredAppWithLock.lockMethod() should be visible on the top of the stack, but it is not, so the "waiting to lock" message is missing from the stack trace. > > I think the explanations mentioned in [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) and [JDK-8269881](https://bugs.openjdk.org/browse/JDK-8269881) apply here also. The state of the thread has moved to BLOCKED, but the thread still needs to finish making an OS call to actually become blocked and the thread become idle. During that time we may not be able to get an accurate stack trace. In this case probably SP has not been flushed, so we are not seeing the lockMethod() frame, which should appear at the top of the stack. > > A short delay has been added after all threads have entered the desired state to make sure they have fully reached the desired state and are now idle. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. Although I don't like using Thread.sleep(), seems there are no any other way to fir the problem. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19953#pullrequestreview-2184368963 From lmesnik at openjdk.org Thu Jul 18 01:07:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 01:07:34 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: <4p89Ssr0eLRG23x49tu4qY51hB6jbnz-r1ZknrJZc54=.830ad843-f3ac-4b60-8efe-a82d4488676f@github.com> On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19864#pullrequestreview-2184371193 From lmesnik at openjdk.org Thu Jul 18 01:08:41 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Jul 2024 01:08:41 GMT Subject: RFR: 8269881: SA stack dump fails to include stack trace for SteadyStateThread In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer wrote: > The completely unrelated fix to [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe that the issue with sometimes not being able to get the stack trace of the SteadyStateThread might be due to the thread being active for a short period after being reported as in the Thread.State.BLOCKED state. Once set to that state, the thread still needs to call a native OS API to block the thread so it is truly idle. During this time the thread stack might be inconsistent and not walk-able. The fix is to add a short sleep after the thread has moved to the Thread.State.BLOCKED state to give it a chance to finish blocking. > > Tested with Tier1 CI and all svc test tasks for tier2 and tier5. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2184371771 From syan at openjdk.org Thu Jul 18 01:54:58 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 01:54:58 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils Message-ID: Hi all, The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. Only change the testcase, the change has been verified, no risk. ------------- Commit messages: - 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils Changes: https://git.openjdk.org/jdk/pull/20228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336691 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20228/head:pull/20228 PR: https://git.openjdk.org/jdk/pull/20228 From syan at openjdk.org Thu Jul 18 02:29:36 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 02:29:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Thanks for the review and approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235174531 From duke at openjdk.org Thu Jul 18 02:29:36 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 02:29:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. @sendaoYan Your change (at version a7c1d63434bbb24122f4256cb695129afac70804) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235175938 From jpai at openjdk.org Thu Jul 18 05:00:32 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:00:32 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 01:49:54 GMT, SendaoYan wrote: > Hi all, > The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. > I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. > Only change the testcase, the change has been verified, no risk. test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 30: > 28: * @library /test/lib > 29: * @modules jdk.attach/sun.tools.attach > 30: * @build jdk.test.lib.Utils jdk.test.lib.apps.LingeredApp LongArgTest Hello @sendaoYan, the test class `LongArgTest` isn't needed in the `@build` set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20228#discussion_r1682116429 From stuefe at openjdk.org Thu Jul 18 05:03:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Jul 2024 05:03:31 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v3] In-Reply-To: <-1Ejx0t2f_Q0Hl9nKsil_C2hweWnB9pTdvbID9_OMtQ=.fa91c0d0-fb81-4e12-b946-a9cdc1125c6c@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <-1Ejx0t2f_Q0Hl9nKsil_C2hweWnB9pTdvbID9_OMtQ=.fa91c0d0-fb81-4e12-b946-a9cdc1125c6c@github.com> Message-ID: On Thu, 18 Jul 2024 00:45:24 GMT, Leonid Mesnik wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates based on feedback > > src/hotspot/share/code/codeCache.cpp line 1791: > >> 1789: >> 1790: #ifdef LINUX >> 1791: void CodeCache::write_perf_map(const char* filename, outputStream* out) { > > I don't think that it is a right place ti expand arguments here. I think it is more consistent to do it in diagnosticCommand.cpp for any jcmd command. So this logic might be the same for any _filename processing. Moreover it would be better be add 'FileArgument' like 'MemorySizeArgument' that correctly parse patterns like %p for all file arguments, used be all commands and be extensible for new macroses if needed. That's a good idea. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1682118709 From dholmes at openjdk.org Thu Jul 18 05:41:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Jul 2024 05:41:31 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 01:49:54 GMT, SendaoYan wrote: > Hi all, > The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. > I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. > Only change the testcase, the change has been verified, no risk. Grepping over all tests I see 666 that import jdk.test.lib.Utils but only 60 actually build it. Looking just at hotspot we have 413 imports and only 1 build! For jdk.test.lib.apps.LingeredApp it is 91 versus 4, in hotspot. I wonder if this is the jtreg issue where compile-on-demand classes are being put in the wrong directory depending on which test in a run first needs it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2235518097 From cjplummer at openjdk.org Thu Jul 18 05:41:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 18 Jul 2024 05:41:31 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:37:31 GMT, David Holmes wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > Grepping over all tests I see 666 that import jdk.test.lib.Utils but only 60 actually build it. Looking just at hotspot we have 413 imports and only 1 build! For jdk.test.lib.apps.LingeredApp it is 91 versus 4, in hotspot. > > I wonder if this is the jtreg issue where compile-on-demand classes are being put in the wrong directory depending on which test in a run first needs it? @dholmes-ora and @alexmenkov should comment in this. Also see my comments that I just added to the CR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2235533308 From dholmes at openjdk.org Thu Jul 18 05:45:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Jul 2024 05:45:30 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: Message-ID: <_XtlSQ30TAMRqwLHID6vutkxQixsAdrH_X3Z_tImp78=.2bbad893-187f-4256-81e6-67e7ed718888@github.com> On Thu, 18 Jul 2024 05:37:31 GMT, David Holmes wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > Grepping over all tests I see 666 that import jdk.test.lib.Utils but only 60 actually build it. Looking just at hotspot we have 413 imports and only 1 build! For jdk.test.lib.apps.LingeredApp it is 91 versus 4, in hotspot. > > I wonder if this is the jtreg issue where compile-on-demand classes are being put in the wrong directory depending on which test in a run first needs it? > @dholmes-ora and @alexmenkov should comment in this. Also see my comments that I just added to the CR. Thanks for the link to https://bugs.openjdk.org/browse/CODETOOLS-7902847 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2235550005 From jpai at openjdk.org Thu Jul 18 05:55:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 05:55:31 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. Hello @sendaoYan, after changes in JDK-8294960, there were a couple of issues reported. From what I see in the linked issues, Adam reviewed those and integrated relevant fixes. In JDK-8334771 you note: > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. So I think we should have this increase in memory reviewed by @asotona or someone familiar in that area, before deciding whether these tests should be changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235607869 From syan at openjdk.org Thu Jul 18 06:26:31 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 06:26:31 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 05:52:51 GMT, Jaikiran Pai wrote: > So I think we should have this increase in memory reviewed by @asotona or someone familiar in that area, before deciding whether these tests should be changed. Okey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2235717028 From syan at openjdk.org Thu Jul 18 07:30:47 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 07:30:47 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: > Hi all, > The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. > I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. > Only change the testcase, the change has been verified, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: delete @build LongArgTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20228/files - new: https://git.openjdk.org/jdk/pull/20228/files/81a3173a..62fc537d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20228&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20228&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20228/head:pull/20228 PR: https://git.openjdk.org/jdk/pull/20228 From syan at openjdk.org Thu Jul 18 07:30:48 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 07:30:48 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 04:57:27 GMT, Jaikiran Pai wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> delete @build LongArgTest > > test/hotspot/jtreg/serviceability/attach/LongArgTest.java line 30: > >> 28: * @library /test/lib >> 29: * @modules jdk.attach/sun.tools.attach >> 30: * @build jdk.test.lib.Utils jdk.test.lib.apps.LingeredApp LongArgTest > > Hello @sendaoYan, the test class `LongArgTest` isn't needed in the `@build` set. Thanks for the review. `LongArgTest` has been deleted in `@build` set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20228#discussion_r1682341391 From sspitsyn at openjdk.org Thu Jul 18 08:42:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 08:42:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 05:58:18 GMT, David Holmes wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/VirtualThread.java line 273: > >> 271: // current thread is a ForkJoinWorkerThread so the task will be pushed >> 272: // to the local queue. For other schedulers, it avoids deadlock that >> 273: // would arise due to platform and virtual threads contenting for a > > s/contenting/contending/ Also noticed this typo. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682450204 From sspitsyn at openjdk.org Thu Jul 18 08:48:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 08:48:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Looks okay. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19864#pullrequestreview-2185137791 From sspitsyn at openjdk.org Thu Jul 18 08:53:34 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 08:53:34 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v2] In-Reply-To: <5w-lZYTr6ZVThJZFscOqVevqSvwvnMXcIB49TuuZIUM=.2b93bc7b-0d7c-4ffd-9811-2846f0502999@github.com> References: <5w-lZYTr6ZVThJZFscOqVevqSvwvnMXcIB49TuuZIUM=.2b93bc7b-0d7c-4ffd-9811-2846f0502999@github.com> Message-ID: On Fri, 12 Jul 2024 09:16:05 GMT, Kevin Walls wrote: >> Short version: >> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" >> >> Make additional typo fixes and tidyups while here, it's just shocking. >> >> TestDescription.java contains the test definition, so the "requires" goes there, with a comment. >> >> Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > formatting Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20146#pullrequestreview-2185148888 From syan at openjdk.org Thu Jul 18 09:08:32 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 09:08:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 08:45:43 GMT, Serguei Spitsyn wrote: > Looks okay. I agree this needs to be reviewed by @asotona . Thanks for the review. I will wait reviewed by @asotona before integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236003849 From asotona at openjdk.org Thu Jul 18 09:15:32 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 09:15:32 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Unfortunately I'm not familiar with these tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236018675 From sspitsyn at openjdk.org Thu Jul 18 10:55:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Jul 2024 10:55:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 Q: There are some new files with a copyright year ranges. They are probably renamed files. Should their copyright years be updated? test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: > 1111: @Test > 1112: void testYield3() throws Exception { > 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); Q: What was the reason to rename `testYield2()` to `testYield3()`? test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 72: > 70: System.out.format("Result: %d in %s ms%n", sum, (end-start)); > 71: if (sum != expected) > 72: throw new RuntimeException("Expected " + expected); Nit: This probably needs a copyright update. ------------- PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2185389469 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682627996 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682604568 From alanb at openjdk.org Thu Jul 18 11:06:33 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 11:06:33 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 10:46:16 GMT, Serguei Spitsyn wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: > >> 1111: @Test >> 1112: void testYield3() throws Exception { >> 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); > > Q: What was the reason to rename `testYield2()` to `testYield3()`? There are a lot of tests that can't be proposed to main line at this time because they depend on the object monitor work. This is one such "gap" where testYield2 can't be added. I can re-number them if you want to avoid the gap but there are other changes that rename several test methods so I'd prefer to leave it until then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1682651423 From alanb at openjdk.org Thu Jul 18 11:20:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Jul 2024 11:20:32 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 10:52:43 GMT, Serguei Spitsyn wrote: > Q: There are some new files with a copyright year ranges. I will check but there are a few renames that have to keep the initial year. Also there are some new files that have been checked into the loom repo for a long time so they have their initial year too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20143#issuecomment-2236251273 From liach at openjdk.org Thu Jul 18 11:23:39 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Jul 2024 11:23:39 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: <7nWS0ihrph2aRmpVm-VU_RPlNwREqwSih4fNE8mrrTY=.f30f081f-cc60-4d77-bae4-e7f448c530f6@github.com> On Thu, 18 Jul 2024 07:30:47 GMT, SendaoYan wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete @build LongArgTest Does this mean that even if libraries are imported with `@library /test/lib` they still need explicit `@build` commands? If that's the case, many core library tests need review as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2236256251 From rkennke at openjdk.org Thu Jul 18 11:33:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 18 Jul 2024 11:33:40 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: > 75: using ConcurrentTable = ConcurrentHashTable; > 76: > 77: ConcurrentTable* _table; So you have a class ObjectMonitorWorld, which references the ConcurrentTable, which, internally also has its actual table. This is 3 dereferences to get to the actual table, if I counted correctly. I'd try to eliminate the outermost ObjectMonitorWorld class, or at least make it a global flat structure instead of a reference to a heap-allocated object. I think, because this is a structure that is global and would exist throughout the lifetime of the Java program anyway, it might be worth figuring out how to do the actual ConcurrentHashTable flat in the global structure, too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1682682065 From syan at openjdk.org Thu Jul 18 11:44:34 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Jul 2024 11:44:34 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. > Unfortunately I'm not familiar with these tests. > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236291264 From jpai at openjdk.org Thu Jul 18 12:30:38 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 12:30:38 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 07:30:47 GMT, SendaoYan wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete @build LongArgTest Hello Chen, > Does this mean that even if libraries are imported with `@library /test/lib` they still need explicit `@build` commands? If that's the case, many core library tests need review as well. Yes, jtreg does expect explicit `@build` for such library usages. It has this to say https://openjdk.org/jtreg/tag-spec.html: > In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2236372312 From asotona at openjdk.org Thu Jul 18 14:08:33 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 18 Jul 2024 14:08:33 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. I can confirm [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) had effect on JDK bootstrap (benchmarked and discussed in https://github.com/openjdk/jdk/pull/17108 ). And there might be measurable differences in various benchmarks sensitive to JDK bootstrap. However I cannot confirm the numbers above, simply because I do not know what they represent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2236630582 From dlunden at openjdk.org Thu Jul 18 15:05:40 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Thu, 18 Jul 2024 15:05:40 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp Message-ID: We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. ### Changeset - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. ------------- Commit messages: - Disable testing with Xcomp Changes: https://git.openjdk.org/jdk/pull/20237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336753 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20237/head:pull/20237 PR: https://git.openjdk.org/jdk/pull/20237 From larry.cable at oracle.com Thu Jul 18 16:22:30 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Thu, 18 Jul 2024 09:22:30 -0700 Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v3] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <-1Ejx0t2f_Q0Hl9nKsil_C2hweWnB9pTdvbID9_OMtQ=.fa91c0d0-fb81-4e12-b946-a9cdc1125c6c@github.com> Message-ID: On 7/17/24 10:03 PM, Thomas Stuefe wrote: > On Thu, 18 Jul 2024 00:45:24 GMT, Leonid Mesnik wrote: > >>> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Updates based on feedback >> src/hotspot/share/code/codeCache.cpp line 1791: >> >>> 1789: >>> 1790: #ifdef LINUX >>> 1791: void CodeCache::write_perf_map(const char* filename, outputStream* out) { >> I don't think that it is a right place ti expand arguments here. I think it is more consistent to do it in diagnosticCommand.cpp for any jcmd command. So this logic might be the same for any _filename processing. Moreover it would be better be add 'FileArgument' like 'MemorySizeArgument' that correctly parse patterns like %p for all file arguments, used be all commands and be extensible for new macroses if needed. > That's a good idea. +1 > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1682118709 From cjplummer at openjdk.org Thu Jul 18 17:19:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 18 Jul 2024 17:19:31 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. I think the proper way to do this would be to add the test to ProblemList-Xcomp.txt, not by using `@requires`, unless we have determined that the nature of the test suggests that it is not appropriate to run with -Xcomp (I haven't seen any evidence of this. yet). That fact that the issue is new would suggest that there is some underlying bug that needs to be better understood. However, I'm not so sure even problem listing is the right thing to do at this point. I don't see any cases of this test timing out in our CI and I don't see any links in the CR to runs that are failing. I do see mach5 adhoc runs failing with the timeout, but they all contains user diffs that could also be related to the cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237111921 From cjplummer at openjdk.org Thu Jul 18 18:55:42 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 18 Jul 2024 18:55:42 GMT Subject: RFR: 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException Message-ID: The test is failing with an ObjectCollectedException. The test hits a SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee side: testedObject = testedClass.newInstance(thread, ctor, params, 0); Since we are under a SUSPEND_ALL, the object is not initially at risk of getting GC'd. However, the test then calls invokeMethod() in a loop: if (method.isStatic()) { voidValue = (VoidValue) testedClass.invokeMethod(thread, method, params, 0); } else { voidValue = (VoidValue) testedObject.invokeMethod(thread, method, params, 0); } On the first iteration of the loop, invokeMethod() will do a resumeAll() so it can execute the method on the specified thread. During this time a GC can happen, and that GC is likely to collect the object that testedObject is mirroring since it is only weakly kept alive. Then on a subsequent iteration of the loop, testedObject.invokeMethod() is called again, but this time you get the ObjectCollectedException because the object that testedObject is mirroring has been collected. The test needs to add a call to testedObject.disableCollection() to prevent it from being collected. I'm not able to reproduce this failure, but the bug is pretty clear. Testing is in progress. I'll run tier1 CI and also tier2 and tier5 test tasks that run this test. ------------- Commit messages: - call disableCollection() on allocated object so it is not collected during the invokeMethod() call Changes: https://git.openjdk.org/jdk/pull/20242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8248609 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20242/head:pull/20242 PR: https://git.openjdk.org/jdk/pull/20242 From kvn at openjdk.org Thu Jul 18 19:57:33 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Jul 2024 19:57:33 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. We don't run this test in CI with the same configuration as in our pre-integration testing. First, we run with "-Xcomp -ea -esa -XX:CompileThreshold=100" flags in CI instead of simple "-Xcomp". Second, we used to be running this test in tier4 on Linux and Tier6 on windows in CI. But now we are running only in tier6 with `any-x64` hosts for which infrastructure always selects linux-x64. On other hand we see timeouts on slow machines macOS-x64 and some Windows machines. This change similar to what we did for other timeout tests recently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237452199 PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237455053 From kvn at openjdk.org Thu Jul 18 20:05:32 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Jul 2024 20:05:32 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. And finally I don't think we should run this test with -Xcomp - there are no any benefits from it. This test dumps java heaps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237466565 From amenkov at openjdk.org Thu Jul 18 20:23:34 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 18 Jul 2024 20:23:34 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 07:30:47 GMT, SendaoYan wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete @build LongArgTest This `@build` tag can solve this particular failure, but can cause similar failures of other tests. I think we need to find out what other test is involved here (I'll add a comment to the CR) and then decide how to fix the issue ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2237492331 From cjplummer at openjdk.org Thu Jul 18 20:25:35 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 18 Jul 2024 20:25:35 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Does not running with `-Xcomp` mean not running it with graal? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237495291 From kvn at openjdk.org Thu Jul 18 20:42:31 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Jul 2024 20:42:31 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 20:22:47 GMT, Chris Plummer wrote: > Does not running with `-Xcomp` mean not running it with graal? `-Xcomp` is not related to graal at all. It triggers all JIT compilers compilation for each called Java method. And Java thread waits until compilation is finished. It is very slow application execution. But it stress JIT compilers since they do a lot more compilations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237534976 From cjplummer at openjdk.org Thu Jul 18 21:18:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 18 Jul 2024 21:18:31 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Given that there is no inherent incompatibility with `-Xcomp` and the test is capable of running with `-Xcomp`, I suggest that you add an `@comment` before the `@require` stating why it shouldn't be run with `-Xcomp`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237631516 From kvn at openjdk.org Thu Jul 18 21:38:33 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Jul 2024 21:38:33 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 21:16:12 GMT, Chris Plummer wrote: > Given that there is no inherent incompatibility with `-Xcomp` and the test is capable of running with `-Xcomp`, I suggest that you add an `@comment` before the `@require` stating why it shouldn't be run with `-Xcomp`. Agree. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2237663241 From amenkov at openjdk.org Thu Jul 18 22:37:31 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 18 Jul 2024 22:37:31 GMT Subject: RFR: 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote: > The test is failing with an ObjectCollectedException. The test hits a SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee side: > > testedObject = testedClass.newInstance(thread, ctor, params, 0); > > Since we are under a SUSPEND_ALL, the object is not initially at risk of getting GC'd. However, the test then calls invokeMethod() in a loop: > > if (method.isStatic()) { > voidValue = (VoidValue) testedClass.invokeMethod(thread, method, params, 0); > } else { > voidValue = (VoidValue) testedObject.invokeMethod(thread, method, params, 0); > } > > On the first iteration of the loop, invokeMethod() will do a resumeAll() so it can execute the method on the specified thread. During this time a GC can happen, and that GC is likely to collect the object that testedObject is mirroring since it is only weakly kept alive. Then on a subsequent iteration of the loop, testedObject.invokeMethod() is called again, but this time you get the ObjectCollectedException because the object that testedObject is mirroring has been collected. The test needs to add a call to testedObject.disableCollection() to prevent it from being collected. > > I'm not able to reproduce this failure, but the bug is pretty clear. Testing is in progress. I'll run tier1 CI and also tier2 and tier5 test tasks that run this test. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20242#pullrequestreview-2187016222 From cjplummer at openjdk.org Fri Jul 19 01:49:00 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 01:49:00 GMT Subject: RFR: 8334145: missing from vm_memory_map_.txt in System.dump_map help text Message-ID: Fix issue with `` argument. ------------- Commit messages: - Fix quoting of pid argument Changes: https://git.openjdk.org/jdk/pull/20246/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334145 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20246/head:pull/20246 PR: https://git.openjdk.org/jdk/pull/20246 From jpai at openjdk.org Fri Jul 19 04:06:42 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 04:06:42 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:42:17 GMT, SendaoYan wrote: >> Hi all, >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. >> Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. >> Only change the testcase, the change has been verified, no risk. > >> Unfortunately I'm not familiar with these tests. > >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. > > Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. @sendaoYan, Given Adam's inputs and the reviews you have had for this change, I think you should be able to go ahead and integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238072647 From dholmes at openjdk.org Fri Jul 19 04:18:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 04:18:32 GMT Subject: RFR: 8334145: missing from vm_memory_map_.txt in System.dump_map help text In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote: > Fix issue with `` argument. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20246#pullrequestreview-2187267950 From dholmes at openjdk.org Fri Jul 19 05:53:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:02 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Note this is simply a re-generation of the troff files from their sources. If there are any problems that need fixing then a new JBS issue has to be filed to update the source file and regenerate the troff file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238248354 From dholmes at openjdk.org Fri Jul 19 05:53:01 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Jul 2024 05:53:01 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC Message-ID: Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. This also picks up the unpublished changes to java.1 from: - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC And a typo crept in to java.1 from: - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal This also picks up the unpublished change to keytool.1 from: - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints This also picks up the unpublished change to javadoc.1 from: - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). Thanks. ------------- Commit messages: - 8325280: Update troff manpages in JDK 23 before RC Changes: https://git.openjdk.org/jdk/pull/20248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325280 Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/20248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20248/head:pull/20248 PR: https://git.openjdk.org/jdk/pull/20248 From syan at openjdk.org Fri Jul 19 06:12:36 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 06:12:36 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:42:17 GMT, SendaoYan wrote: >> Hi all, >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. >> Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. >> Only change the testcase, the change has been verified, no risk. > >> Unfortunately I'm not familiar with these tests. > >> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the codecache usage increased significantly, non-profiled 3068Kb->3583Kb, profiled 6408Kb->7846Kb. > > Can you confirm that the codecache usage increased is expected or not after [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960) with -Xcomp jvm option. > @sendaoYan, Given Adam's inputs and the reviews you have had for this change, I think you should be able to go ahead and integrate this. Thanks all for the review. Can you sponsor this PR for me. @jaikiran ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238306043 From duke at openjdk.org Fri Jul 19 06:12:37 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 06:12:37 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. @sendaoYan Your change (at version a7c1d63434bbb24122f4256cb695129afac70804) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238311075 From syan at openjdk.org Fri Jul 19 07:10:37 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 07:10:37 GMT Subject: RFR: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. Thanks for the sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19864#issuecomment-2238518349 From syan at openjdk.org Fri Jul 19 07:10:38 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Jul 2024 07:10:38 GMT Subject: Integrated: 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 In-Reply-To: References: Message-ID: <0QhSjAuTPmCWwJIkMyPmeMjN_RpNMFeQQ-h44p2LOBo=.e8d47427-a3d3-4f30-aa45-65b19bc1eb7d@github.com> On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote: > Hi all, > After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the footprint memory usage increased significantly when run the testcase with -Xcomp jvm options, then cause the testcase was killed by docker by OOM. > Maybe the footprint memory usage increased was inevitable, so I think we should increase the smallest memory limite for this testcase. > Only change the testcase, the change has been verified, no risk. This pull request has now been integrated. Changeset: fa5ad700 Author: SendaoYan Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/fa5ad700bb6a92aef7577969e09b4fbd93feb388 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 8334771: [TESTBUG] Run TestDockerMemoryMetrics.java with -Xcomp fails exitValue = 137 Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/19864 From thartmann at openjdk.org Fri Jul 19 07:19:32 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 19 Jul 2024 07:19:32 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. FTR, I converted this to a sub-task of [JDK-8336805](https://bugs.openjdk.org/browse/JDK-8336805) which keeps track of the regression from [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241) that we think is responsible for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2238531192 From sspitsyn at openjdk.org Fri Jul 19 08:00:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 19 Jul 2024 08:00:36 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 11:18:08 GMT, Alan Bateman wrote: > I will check but there are a few renames that have to keep the initial year. Also there are some new files that have been checked into the loom repo for a long time so they have their initial year too. Okay, thanks. >> test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 1113: >> >>> 1111: @Test >>> 1112: void testYield3() throws Exception { >>> 1113: assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers"); >> >> Q: What was the reason to rename `testYield2()` to `testYield3()`? > > There are a lot of tests that can't be proposed to main line at this time because they depend on the object monitor work. This is one such "gap" where testYield2 can't be added. I can re-number them if you want to avoid the gap but there are other changes that rename several test methods so I'd prefer to leave it until then. Okay, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20143#issuecomment-2238590482 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1683973972 From alanb at openjdk.org Fri Jul 19 08:29:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Jul 2024 08:29:36 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by alanb (Reviewer). Thanks for the tireless effort to update the man pages at the end of each release. ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2187669729 PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2238647463 From dlunden at openjdk.org Fri Jul 19 09:11:36 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 09:11:36 GMT Subject: Withdrawn: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20237 From dlunden at openjdk.org Fri Jul 19 09:31:01 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 09:31:01 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v2] In-Reply-To: References: Message-ID: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: Add comment and bug number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20237/files - new: https://git.openjdk.org/jdk/pull/20237/files/e3aa2a73..2648fab2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20237/head:pull/20237 PR: https://git.openjdk.org/jdk/pull/20237 From dlunden at openjdk.org Fri Jul 19 09:31:01 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 09:31:01 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Thanks for the input everyone. I've now added a comment based on the discussion above, and I also added this issue number to the test for tracking purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2238750002 From thartmann at openjdk.org Fri Jul 19 09:48:32 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 19 Jul 2024 09:48:32 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v2] In-Reply-To: References: Message-ID: <3gcT_O7jPWGv7DYYMc5frHkhCD2fGK38Ubyk3dEhCuI=.b918a4a4-5f95-43bd-aa9d-4b95dd1b0c34@github.com> On Fri, 19 Jul 2024 09:31:01 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Add comment and bug number Looks good to me otherwise. test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java line 40: > 38: /** > 39: * @test > 40: * @bug 8240989 8336753 I don't think that change makes sense because the test is not a regression test for JDK-8336753. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20237#pullrequestreview-2187828134 PR Review Comment: https://git.openjdk.org/jdk/pull/20237#discussion_r1684135244 From dlunden at openjdk.org Fri Jul 19 09:53:33 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 09:53:33 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v2] In-Reply-To: <3gcT_O7jPWGv7DYYMc5frHkhCD2fGK38Ubyk3dEhCuI=.b918a4a4-5f95-43bd-aa9d-4b95dd1b0c34@github.com> References: <3gcT_O7jPWGv7DYYMc5frHkhCD2fGK38Ubyk3dEhCuI=.b918a4a4-5f95-43bd-aa9d-4b95dd1b0c34@github.com> Message-ID: On Fri, 19 Jul 2024 09:45:19 GMT, Tobias Hartmann wrote: >> Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment and bug number > > test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java line 40: > >> 38: /** >> 39: * @test >> 40: * @bug 8240989 8336753 > > I don't think that change makes sense because the test is not a regression test for JDK-8336753. Can/should I include the bug number in some other way (perhaps directly in the comment)? I'm thinking if someone reads the comment in the future and would like more details. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20237#discussion_r1684141326 From thartmann at openjdk.org Fri Jul 19 10:44:32 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 19 Jul 2024 10:44:32 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v2] In-Reply-To: References: <3gcT_O7jPWGv7DYYMc5frHkhCD2fGK38Ubyk3dEhCuI=.b918a4a4-5f95-43bd-aa9d-4b95dd1b0c34@github.com> Message-ID: <2tSa2N-tRMenfpMxjWYudzUsmxu4y2oIIWQAIOKUxUc=.254ba4c2-cfd0-4275-a357-ba1e806927c5@github.com> On Fri, 19 Jul 2024 09:50:43 GMT, Daniel Lund?n wrote: >> test/hotspot/jtreg/serviceability/sa/ClhsdbDumpheap.java line 40: >> >>> 38: /** >>> 39: * @test >>> 40: * @bug 8240989 8336753 >> >> I don't think that change makes sense because the test is not a regression test for JDK-8336753. > > Can/should I include the bug number in some other way (perhaps directly in the comment)? I'm thinking if someone reads the comment in the future and would like more details. I don't think that's necessary, one can always find the changeset that added a specific line/comment via the git history. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20237#discussion_r1684193424 From dlunden at openjdk.org Fri Jul 19 11:50:03 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 11:50:03 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v3] In-Reply-To: References: Message-ID: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: Remove issue number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20237/files - new: https://git.openjdk.org/jdk/pull/20237/files/2648fab2..05eddeb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20237/head:pull/20237 PR: https://git.openjdk.org/jdk/pull/20237 From dlunden at openjdk.org Fri Jul 19 11:50:03 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Fri, 19 Jul 2024 11:50:03 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v2] In-Reply-To: <2tSa2N-tRMenfpMxjWYudzUsmxu4y2oIIWQAIOKUxUc=.254ba4c2-cfd0-4275-a357-ba1e806927c5@github.com> References: <3gcT_O7jPWGv7DYYMc5frHkhCD2fGK38Ubyk3dEhCuI=.b918a4a4-5f95-43bd-aa9d-4b95dd1b0c34@github.com> <2tSa2N-tRMenfpMxjWYudzUsmxu4y2oIIWQAIOKUxUc=.254ba4c2-cfd0-4275-a357-ba1e806927c5@github.com> Message-ID: On Fri, 19 Jul 2024 10:42:00 GMT, Tobias Hartmann wrote: >> Can/should I include the bug number in some other way (perhaps directly in the comment)? I'm thinking if someone reads the comment in the future and would like more details. > > I don't think that's necessary, one can always find the changeset that added a specific line/comment via the git history. Fair enough, now removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20237#discussion_r1684254758 From thartmann at openjdk.org Fri Jul 19 12:03:34 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 19 Jul 2024 12:03:34 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v3] In-Reply-To: References: Message-ID: <0yjrYvOeClKSSAKUvL4A5BiATPQx91HWCG8g4ndgeig=.ca40871c-bdf5-45d8-a2c1-df0d87077f9b@github.com> On Fri, 19 Jul 2024 11:50:03 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Remove issue number Marked as reviewed by thartmann (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20237#pullrequestreview-2188057000 From aturbanov at openjdk.org Fri Jul 19 12:16:31 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 19 Jul 2024 12:16:31 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: <3p2YR8paCauJdaCur6ZE_G5eOzcV_Dzssfhb3mV7u4w=.928ed8e6-07bc-4db0-bd82-9a7fc22397a2@github.com> On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java line 216: > 214: var started = new CountDownLatch(1); > 215: var entered = new AtomicBoolean(); > 216: Thread vthread = Thread.ofVirtual().unstarted(() -> { Suggestion: Thread vthread = Thread.ofVirtual().unstarted(() -> { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1684290798 From aturbanov at openjdk.org Fri Jul 19 12:19:37 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 19 Jul 2024 12:19:37 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 126: > 124: int count = getCount(); > 125: if (count != i * THREADS) { > 126: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count + Suggestion: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count + test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 136: > 134: int count = getCount(); > 135: if (count != ITERATIONS * THREADS) { > 136: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count); Suggestion: throw new RuntimeException("WaitNotifyTest: Invalid Count " + count); test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 217: > 215: int count = getCount(); > 216: if (count != THREADS * ITERATIONS) { > 217: throw new RuntimeException("RandomDepthTest: Invalid Count " + count); Suggestion: throw new RuntimeException("RandomDepthTest: Invalid Count " + count); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293578 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293811 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1684293954 From szaldana at openjdk.org Fri Jul 19 13:51:17 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 13:51:17 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v4] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision: - Adding tests for file dcmd argument - Updates to test case - Adding FileArgument as a diagnostic argument ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/3bb774d3..c71cb639 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=02-03 Stats: 146 lines in 11 files changed: 76 ins; 46 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Fri Jul 19 14:07:12 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 14:07:12 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Missing copyright header update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/c71cb639..cdf1d457 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Fri Jul 19 14:07:12 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 14:07:12 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v4] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 13:51:17 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision: > > - Adding tests for file dcmd argument > - Updates to test case > - Adding FileArgument as a diagnostic argument Hi folks, I made some updates. Just wanted to note a few things: * I think we can remove `test/jdk/sun/tools/jcmd/TestJcmdPIDSubstitution.java` and the changes to test/hotspot/jtreg/runtime/cds/appcds/jcmd tests. I?ve added a test case for dcmd file argument parsing which is more general. I?ve left the old tests in for reference at the moment. * Regarding warnings, I noted we wanted to issue any warnings to the issuer of the dcmd and not the JVM process. However, in ```diagnosticArgument.cpp```, they are issuing the warnings directly to the JVM process. I tried to stay consistent with how things are done there, but let me know what you think. Thanks for the comments! Sonia ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2239256942 From kvn at openjdk.org Fri Jul 19 14:55:34 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 19 Jul 2024 14:55:34 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 11:50:03 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Remove issue number Last update is good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20237#pullrequestreview-2188438125 From cjplummer at openjdk.org Fri Jul 19 16:52:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 16:52:33 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 11:50:03 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Remove issue number Copyright needs updating. ------------- PR Review: https://git.openjdk.org/jdk/pull/20237#pullrequestreview-2188683762 From alanb at openjdk.org Fri Jul 19 16:59:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Jul 2024 16:59:54 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 Alan Bateman 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 eight additional commits since the last revision: - Merge - Fix typo in comment, missing copyright update, test nits - Merge - Drop JLA updates for this update - Merge - Merge - Update copyright headers - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20143/files - new: https://git.openjdk.org/jdk/pull/20143/files/1fad7dff..2d3bbf46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20143&range=00-01 Stats: 4362 lines in 184 files changed: 2873 ins; 856 del; 633 mod Patch: https://git.openjdk.org/jdk/pull/20143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20143/head:pull/20143 PR: https://git.openjdk.org/jdk/pull/20143 From iris at openjdk.org Fri Jul 19 17:21:32 2024 From: iris at openjdk.org (Iris Clark) Date: Fri, 19 Jul 2024 17:21:32 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20248#pullrequestreview-2188754909 From cjplummer at openjdk.org Fri Jul 19 18:45:40 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 18:45:40 GMT Subject: RFR: 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep Message-ID: The test sometimes fails because the InterruptException doesn't arrive during the 100ms that the thread sleeps. My suspicion is that the interrupt is being delayed for some external reason, like temporary load on the host. I'm bumping the sleep period to 10s to hopefully avoid such an issue. This won't make the test run any slower when it passes, but will make it slower (by about 10 seconds) when it fails due to waiting longer for the InterruptException to never arrive, assuming it still might fail for this reason. I tested by running the InterruptHangTest locally. TBD I will run all of con/sun/jdi on all supported platforms. ------------- Commit messages: - Allow for a much longer sleep while waiting for the interrupt to arrive Changes: https://git.openjdk.org/jdk/pull/20263/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20263&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333391 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20263.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20263/head:pull/20263 PR: https://git.openjdk.org/jdk/pull/20263 From szaldana at openjdk.org Fri Jul 19 18:57:40 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 18:57:40 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() Message-ID: Hi all, This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. Testing: - [x] Added test case passes. Thanks, Sonia ------------- Commit messages: - 8327054: DiagnosticCommand Compiler.perfmap does not log on output() Changes: https://git.openjdk.org/jdk/pull/20257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327054 Stats: 16 lines in 5 files changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20257/head:pull/20257 PR: https://git.openjdk.org/jdk/pull/20257 From cjplummer at openjdk.org Fri Jul 19 19:23:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 19:23:31 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:07:39 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 124: > 122: output.shouldContain("Failed to create nonexistent/%s for perf map".formatted(test_dir)); > 123: output.shouldNotHaveExitValue(0); > 124: Files.deleteIfExists(path); If the file exists, that means the expected error message will not be found, which means an exception will be thrown before you get to the `Files.deleteIfExits(path)` call. If the file doesn't exist, then there is nothing to delete. So as things stand now this call will never delete anything. Maybe put it in a finally block so if the file does exist it will get deleted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1684890829 From lmesnik at openjdk.org Fri Jul 19 20:10:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Jul 2024 20:10:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 14:07:12 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Missing copyright header update Thanks for updating the fix. The new version looks moistly good. I added a few small comments. src/hotspot/share/prims/wbtestmethods/parserTests.cpp line 132: > 130: } else if (strcmp(type, "FILE") == 0) { > 131: DCmdArgument *argument = > 132: new DCmdArgument(name, desc, "FILE", mandatory); Please check indentation. src/hotspot/share/services/diagnosticArgument.cpp line 358: > 356: template <> void DCmdArgument::destroy_value() { } > 357: > 358: template <> The common style here is to place in the single line 'template<> and other part of declaration. src/hotspot/share/services/diagnosticArgument.cpp line 366: > 364: _value._name = NEW_C_HEAP_ARRAY(char, JVM_MAXPATHLEN, mtInternal); > 365: if (!Arguments::copy_expand_pid(str, len, _value._name, JVM_MAXPATHLEN)) { > 366: fatal("Invalid file path: %s", str); As I understand the 'copy_expand_pid' might fail if very long line is used. This cause jvm crash., So there is possibility that user might crash jvm accidentally invoking jcmd command. It doesn't look safe, I believe it would be better to throw Exception like for any other invalid command, see " THROW_MSG(vmSymbols::java_lang_IllegalArgumentException()," The 'fatal" owuld make sense only if failing of 'copy_expand_pid' means some unrecoverable jvm bug. ------------- Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2189044201 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1684887604 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1684892964 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1684923626 From lmesnik at openjdk.org Fri Jul 19 20:10:35 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Jul 2024 20:10:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v4] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 14:03:43 GMT, Sonia Zaldana Calles wrote: > * Regarding warnings, I noted we wanted to issue any warnings to the issuer of the dcmd and not the JVM process. However, in `diagnosticArgument.cpp`, they are issuing the warnings directly to the JVM process. I tried to stay consistent with how things are done there, but let me know what you think. > It makes sense to file separate issue for this and keep current behavior in the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2240037485 From lmesnik at openjdk.org Fri Jul 19 20:15:36 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Jul 2024 20:15:36 GMT Subject: RFR: 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote: > The test sometimes fails because the InterruptException doesn't arrive during the 100ms that the thread sleeps. My suspicion is that the interrupt is being delayed for some external reason, like temporary load on the host. I'm bumping the sleep period to 10s to hopefully avoid such an issue. This won't make the test run any slower when it passes, but will make it slower (by about 10 seconds) when it fails due to waiting longer for the InterruptException to never arrive, assuming it still might fail for this reason. > > I tested by running the InterruptHangTest locally. TBD I will run all of con/sun/jdi on all supported platforms. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20263#pullrequestreview-2189118504 From szaldana at openjdk.org Fri Jul 19 20:17:46 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 20:17:46 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v2] In-Reply-To: References: Message-ID: <1IQ-_rNXXSFB9LAsP0kbK3MAQSOgKKrqZxFC8tZzrkc=.8b2c00dd-bddf-4362-9125-36ad2042e794@github.com> > Hi all, > > This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Ensuring test case deletes file in case of exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20257/files - new: https://git.openjdk.org/jdk/pull/20257/files/484f25eb..6129d87c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=00-01 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20257/head:pull/20257 PR: https://git.openjdk.org/jdk/pull/20257 From szaldana at openjdk.org Fri Jul 19 20:17:46 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 19 Jul 2024 20:17:46 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v2] In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 19:21:05 GMT, Chris Plummer wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Ensuring test case deletes file in case of exception > > test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 124: > >> 122: output.shouldContain("Failed to create nonexistent/%s for perf map".formatted(test_dir)); >> 123: output.shouldNotHaveExitValue(0); >> 124: Files.deleteIfExists(path); > > If the file exists, that means the expected error message will not be found, which means an exception will be thrown before you get to the `Files.deleteIfExits(path)` call. If the file doesn't exist, then there is nothing to delete. So as things stand now this call will never delete anything. Maybe put it in a finally block so if the file does exist it will get deleted. Makes sense, I added the finally block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1684933809 From lmesnik at openjdk.org Fri Jul 19 20:54:33 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Jul 2024 20:54:33 GMT Subject: RFR: 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote: > The test is failing with an ObjectCollectedException. The test hits a SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee side: > > testedObject = testedClass.newInstance(thread, ctor, params, 0); > > Since we are under a SUSPEND_ALL, the object is not initially at risk of getting GC'd. However, the test then calls invokeMethod() in a loop: > > if (method.isStatic()) { > voidValue = (VoidValue) testedClass.invokeMethod(thread, method, params, 0); > } else { > voidValue = (VoidValue) testedObject.invokeMethod(thread, method, params, 0); > } > > On the first iteration of the loop, invokeMethod() will do a resumeAll() so it can execute the method on the specified thread. During this time a GC can happen, and that GC is likely to collect the object that testedObject is mirroring since it is only weakly kept alive. Then on a subsequent iteration of the loop, testedObject.invokeMethod() is called again, but this time you get the ObjectCollectedException because the object that testedObject is mirroring has been collected. The test needs to add a call to testedObject.disableCollection() to prevent it from being collected. > > I'm not able to reproduce this failure, but the bug is pretty clear. Testing is in progress. I'll run tier1 CI and also tier2 and tier5 test tasks that run this test. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20242#pullrequestreview-2189211759 From cjplummer at openjdk.org Fri Jul 19 21:54:41 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 21:54:41 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v2] In-Reply-To: <1IQ-_rNXXSFB9LAsP0kbK3MAQSOgKKrqZxFC8tZzrkc=.8b2c00dd-bddf-4362-9125-36ad2042e794@github.com> References: <1IQ-_rNXXSFB9LAsP0kbK3MAQSOgKKrqZxFC8tZzrkc=.8b2c00dd-bddf-4362-9125-36ad2042e794@github.com> Message-ID: On Fri, 19 Jul 2024 20:17:46 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Ensuring test case deletes file in case of exception Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20257#pullrequestreview-2189401873 From cjplummer at openjdk.org Fri Jul 19 21:55:50 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 21:55:50 GMT Subject: RFR: 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote: > The test is failing with an ObjectCollectedException. The test hits a SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee side: > > testedObject = testedClass.newInstance(thread, ctor, params, 0); > > Since we are under a SUSPEND_ALL, the object is not initially at risk of getting GC'd. However, the test then calls invokeMethod() in a loop: > > if (method.isStatic()) { > voidValue = (VoidValue) testedClass.invokeMethod(thread, method, params, 0); > } else { > voidValue = (VoidValue) testedObject.invokeMethod(thread, method, params, 0); > } > > On the first iteration of the loop, invokeMethod() will do a resumeAll() so it can execute the method on the specified thread. During this time a GC can happen, and that GC is likely to collect the object that testedObject is mirroring since it is only weakly kept alive. Then on a subsequent iteration of the loop, testedObject.invokeMethod() is called again, but this time you get the ObjectCollectedException because the object that testedObject is mirroring has been collected. The test needs to add a call to testedObject.disableCollection() to prevent it from being collected. > > I'm not able to reproduce this failure, but the bug is pretty clear. Testing is in progress. I'll run tier1 CI and also tier2 and tier5 test tasks that run this test. Thank you for the reviews Alex and Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20242#issuecomment-2240267099 From cjplummer at openjdk.org Fri Jul 19 21:55:50 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 19 Jul 2024 21:55:50 GMT Subject: Integrated: 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 18:50:48 GMT, Chris Plummer wrote: > The test is failing with an ObjectCollectedException. The test hits a SUSPEND_ALL breakpoint. It then uses JDI to allocate an Object on the debuggee side: > > testedObject = testedClass.newInstance(thread, ctor, params, 0); > > Since we are under a SUSPEND_ALL, the object is not initially at risk of getting GC'd. However, the test then calls invokeMethod() in a loop: > > if (method.isStatic()) { > voidValue = (VoidValue) testedClass.invokeMethod(thread, method, params, 0); > } else { > voidValue = (VoidValue) testedObject.invokeMethod(thread, method, params, 0); > } > > On the first iteration of the loop, invokeMethod() will do a resumeAll() so it can execute the method on the specified thread. During this time a GC can happen, and that GC is likely to collect the object that testedObject is mirroring since it is only weakly kept alive. Then on a subsequent iteration of the loop, testedObject.invokeMethod() is called again, but this time you get the ObjectCollectedException because the object that testedObject is mirroring has been collected. The test needs to add a call to testedObject.disableCollection() to prevent it from being collected. > > I'm not able to reproduce this failure, but the bug is pretty clear. Testing is in progress. I'll run tier1 CI and also tier2 and tier5 test tasks that run this test. This pull request has now been integrated. Changeset: e7e48a78 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/e7e48a780a34007994f830869fdb74ba1cb5b3fe Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8248609: [Graal] vmTestbase/nsk/jdi/VoidValue/toString/tostring001/TestDescription.java failed with Unexpected com.sun.jdi.ObjectCollectedException Reviewed-by: amenkov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/20242 From dlunden at openjdk.org Sat Jul 20 06:33:09 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Sat, 20 Jul 2024 06:33:09 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v3] In-Reply-To: References: Message-ID: <2Y7QfxmGl40FbxmLGax-4d52143fXLmno4R_Wugrpoc=.b1295f5f-20d2-42c4-a3de-0657f858b523@github.com> On Fri, 19 Jul 2024 16:49:56 GMT, Chris Plummer wrote: > Copyright needs updating. Thanks, done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2240950444 From dlunden at openjdk.org Sat Jul 20 06:33:09 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Sat, 20 Jul 2024 06:33:09 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v4] In-Reply-To: References: Message-ID: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20237/files - new: https://git.openjdk.org/jdk/pull/20237/files/05eddeb1..1ab05291 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20237&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20237/head:pull/20237 PR: https://git.openjdk.org/jdk/pull/20237 From stuefe at openjdk.org Sat Jul 20 08:07:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 08:07:33 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 14:07:12 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Missing copyright header update Moistly good too. Remarks inline. src/hotspot/share/services/diagnosticArgument.cpp line 384: > 382: _value._name = nullptr; > 383: } > 384: } Whatever this `DCmdArgument::destroy_value()` is supposed to do, it clearly isn't working, since we leak the memory. src/hotspot/share/services/diagnosticArgument.hpp line 66: > 64: public: > 65: char *_name; > 66: }; Something is off about this. What is the lifetime of this object? You don't free it. Running a command in a loop will consume C-heap (you can check this with NMT: `jcmd VM.native_memory baseline`, then run a command 100 times, then `jcmd VM.native_memory summary.diff` will show you the leak in mtInternal. I would probably just inline the string. E.g. struct FileArgument { char name[max name len] }; FileArguments sits as member inside DCmdArgument. DCmdArgument or DCmdArgumentWithParser sits as member in the various XXXDCmd classes. Those are created in DCmdFactory::create_local_DCmd(). Which is what, a static global list? So we only have one global XXXDCmd object instance per command, but for each command invocation re-parse the argument values? What a weird concept. Man, this coding is way too convoluted for a little parser engine :( But anyway, inlining the filename array into FileArgument should be probably fine from a size standpoint. I would, however, not use JVM_MAXPATHLEN or anything that depends ultimately on PATH_MAX from system headers. We don't want the object to consume e.g. an MB if some crazy platform defines PATH_MAX as 1MB. Therefore I would use e.g. 1024 as limit for the path name. (Note that PATH_MAX is an illusion anyway, there is never a guarantee that a path is smaller than that limit... See this good article: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html) src/hotspot/share/services/diagnosticArgument.hpp line 113: > 111: void to_string(MemorySizeArgument f, char* buf, size_t len) const; > 112: void to_string(StringArrayArgument* s, char* buf, size_t len) const; > 113: void to_string(FileArgument f, char *buf, size_t len) const; Here, and in all other places: Please use 'char* var', not 'char *var'. ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2189782275 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685301655 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685297940 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685290041 From stuefe at openjdk.org Sat Jul 20 08:07:34 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 08:07:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 20:00:28 GMT, Leonid Mesnik wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing copyright header update > > src/hotspot/share/services/diagnosticArgument.cpp line 366: > >> 364: _value._name = NEW_C_HEAP_ARRAY(char, JVM_MAXPATHLEN, mtInternal); >> 365: if (!Arguments::copy_expand_pid(str, len, _value._name, JVM_MAXPATHLEN)) { >> 366: fatal("Invalid file path: %s", str); > > As I understand the 'copy_expand_pid' might fail if very long line is used. This cause jvm crash., > So there is possibility that user might crash jvm accidentally invoking jcmd command. > It doesn't look safe, I believe it would be better to throw Exception like for any other invalid command, see > " THROW_MSG(vmSymbols::java_lang_IllegalArgumentException()," > > The 'fatal" owuld make sense only if failing of 'copy_expand_pid' means some unrecoverable jvm bug. Yes. In this file, other commands use `fatal` only where reading the hard-coded default values - in the various `init_...` functions. Hard-coded values should be valid, obviously, otherwise the JVM developer messed up. Other values are passed in by the end user via jcmd and should not crash the JVM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685299871 From stuefe at openjdk.org Sat Jul 20 08:07:34 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 08:07:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 20 Jul 2024 07:38:25 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/diagnosticArgument.cpp line 366: >> >>> 364: _value._name = NEW_C_HEAP_ARRAY(char, JVM_MAXPATHLEN, mtInternal); >>> 365: if (!Arguments::copy_expand_pid(str, len, _value._name, JVM_MAXPATHLEN)) { >>> 366: fatal("Invalid file path: %s", str); >> >> As I understand the 'copy_expand_pid' might fail if very long line is used. This cause jvm crash., >> So there is possibility that user might crash jvm accidentally invoking jcmd command. >> It doesn't look safe, I believe it would be better to throw Exception like for any other invalid command, see >> " THROW_MSG(vmSymbols::java_lang_IllegalArgumentException()," >> >> The 'fatal" owuld make sense only if failing of 'copy_expand_pid' means some unrecoverable jvm bug. > > Yes. In this file, other commands use `fatal` only where reading the hard-coded default values - in the various `init_...` functions. Hard-coded values should be valid, obviously, otherwise the JVM developer messed up. Other values are passed in by the end user via jcmd and should not crash the JVM. I see the prevalent way to deal with runtime parse errors is to throw a java exception. That exception later is caught in the command processing loop at the entrance of the attach listener thread. So, @SoniaZaldana, I would do this here too - when in Rome... But is this not unnecessarily complex? It requires the AttachListener to be a java thread when in fact it does need no java - we just misuse java exception handling as a way to pass error information up the stack, with the simple ultimate goal of writing error information into the outputStream to be sent to the caller. We might just as well pass the outputStream* to the parse_xxx functions as third argument, and write directly and return some error code. This would make the attach listener thread a lot less dependent on Java and more robust - at least for jcmds that don't need Java (which jcmds need java?). After all, the attach listener is supposed to be super robust and always work even if the JVM misbehaves. @dholmes-ora @lmesnik what do you guys think, should we change that? (obviously in a different RFE) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685304522 From stuefe at openjdk.org Sat Jul 20 08:07:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 08:07:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 20 Jul 2024 07:30:55 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing copyright header update > > src/hotspot/share/services/diagnosticArgument.hpp line 66: > >> 64: public: >> 65: char *_name; >> 66: }; > > Something is off about this. What is the lifetime of this object? > > You don't free it. Running a command in a loop will consume C-heap (you can check this with NMT: `jcmd VM.native_memory baseline`, then run a command 100 times, then `jcmd VM.native_memory summary.diff` will show you the leak in mtInternal. > > I would probably just inline the string. E.g. > > > struct FileArgument { > char name[max name len] > }; > > > FileArguments sits as member inside DCmdArgument. DCmdArgument or DCmdArgumentWithParser sits as member in the various XXXDCmd classes. > > Those are created in DCmdFactory::create_local_DCmd(). Which is what, a static global list? So we only have one global XXXDCmd object instance per command, but for each command invocation re-parse the argument values? What a weird concept. > > Man, this coding is way too convoluted for a little parser engine :( > > But anyway, inlining the filename array into FileArgument should be probably fine from a size standpoint. I would, however, not use JVM_MAXPATHLEN or anything that depends ultimately on PATH_MAX from system headers. We don't want the object to consume e.g. an MB if some crazy platform defines PATH_MAX as 1MB. Therefore I would use e.g. 1024 as limit for the path name. > > (Note that PATH_MAX is an illusion anyway, there is never a guarantee that a path is smaller than that limit... See this good article: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html) Note that the reason for the leak is probably the fact that you don't clear old values on parse_value. See e.g. how char* does it. However, since you allocate with a constant size anyway, the buffer size never changes, you could just as well either follow my advice above (inlining), or just re-use the existing pointer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685308132 From stuefe at openjdk.org Sat Jul 20 10:52:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 10:52:31 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v2] In-Reply-To: <1IQ-_rNXXSFB9LAsP0kbK3MAQSOgKKrqZxFC8tZzrkc=.8b2c00dd-bddf-4362-9125-36ad2042e794@github.com> References: <1IQ-_rNXXSFB9LAsP0kbK3MAQSOgKKrqZxFC8tZzrkc=.8b2c00dd-bddf-4362-9125-36ad2042e794@github.com> Message-ID: On Fri, 19 Jul 2024 20:17:46 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Ensuring test case deletes file in case of exception src/hotspot/share/code/codeCache.hpp line 226: > 224: static void print_summary(outputStream* st, bool detailed = true); // Prints a summary of the code cache usage > 225: static void log_state(outputStream* st); > 226: LINUX_ONLY(static void write_perf_map(const char* filename, outputStream* st);) Please add a comment about what the stream `st` is supposed to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1685374253 From jsjolen at openjdk.org Sat Jul 20 11:22:32 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 20 Jul 2024 11:22:32 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 19 Jul 2024 19:17:54 GMT, Leonid Mesnik wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing copyright header update > > src/hotspot/share/prims/wbtestmethods/parserTests.cpp line 132: > >> 130: } else if (strcmp(type, "FILE") == 0) { >> 131: DCmdArgument *argument = >> 132: new DCmdArgument(name, desc, "FILE", mandatory); > > Please check indentation. On top: We hug the `*`s next to the type in Hotspot, not next to the var name. So `DCmdArgument* argument`. This is something to check for all new code. Pre-existing: The indentation of the if-block is wrong. Also, @SoniaZaldana, would you mind changing the code to this (does not include your change), the repetition just made me cringe ?. ```c++ DCmdArgument* argument = nullptr; if (strcmp(type, "STRING") == 0) { argument = new DCmdArgument(name, desc, "STRING", mandatory, default_value); } else if (strcmp(type, "NANOTIME") == 0) { DCmdArgument* argument = new DCmdArgument(name, desc, "NANOTIME", mandatory, default_value); } else if (strcmp(type, "JLONG") == 0) { DCmdArgument* argument = new DCmdArgument(name, desc, "JLONG", mandatory, default_value); } else if (strcmp(type, "BOOLEAN") == 0) { DCmdArgument* argument = new DCmdArgument(name, desc, "BOOLEAN", mandatory, default_value); } else if (strcmp(type, "MEMORYSIZE") == 0) { DCmdArgument* argument = new DCmdArgument(name, desc, "MEMORY SIZE", mandatory, default_value); } else if (strcmp(type, "STRINGARRAY") == 0) { DCmdArgument* argument = new DCmdArgument(name, desc, "STRING SET", mandatory); } if (argument != nullptr) { if (isarg) { parser->add_dcmd_argument(argument); } else { parser->add_dcmd_option(argument); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685384131 From stuefe at openjdk.org Sat Jul 20 12:09:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Jul 2024 12:09:31 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 20 Jul 2024 11:18:34 GMT, Johan Sj?len wrote: >> src/hotspot/share/prims/wbtestmethods/parserTests.cpp line 132: >> >>> 130: } else if (strcmp(type, "FILE") == 0) { >>> 131: DCmdArgument *argument = >>> 132: new DCmdArgument(name, desc, "FILE", mandatory); >> >> Please check indentation. > > On top: We hug the `*`s next to the type in Hotspot, not next to the var name. So `DCmdArgument* argument`. This is something to check for all new code. > > Pre-existing: The indentation of the if-block is wrong. > > Also, @SoniaZaldana, would you mind changing the code to this (does not include your change), the repetition just made me cringe ?. > > ```c++ > DCmdArgument* argument = nullptr; > if (strcmp(type, "STRING") == 0) { > argument = new DCmdArgument(name, desc, "STRING", mandatory, default_value); > } else if (strcmp(type, "NANOTIME") == 0) { > DCmdArgument* argument = new DCmdArgument(name, desc, "NANOTIME", mandatory, default_value); > } else if (strcmp(type, "JLONG") == 0) { > DCmdArgument* argument = new DCmdArgument(name, desc, "JLONG", mandatory, default_value); > } else if (strcmp(type, "BOOLEAN") == 0) { > DCmdArgument* argument = new DCmdArgument(name, desc, "BOOLEAN", mandatory, default_value); > } else if (strcmp(type, "MEMORYSIZE") == 0) { > DCmdArgument* argument = new DCmdArgument(name, desc, "MEMORY SIZE", mandatory, default_value); > } else if (strcmp(type, "STRINGARRAY") == 0) { > DCmdArgument* argument = new DCmdArgument(name, desc, "STRING SET", mandatory); > } > > if (argument != nullptr) { > if (isarg) { > parser->add_dcmd_argument(argument); > } else { > parser->add_dcmd_option(argument); > } > } @jdksjolen > Also, @SoniaZaldana, would you mind changing the code to this Even simpler (did not test, but you get my drift): #define ALL_TYPES_DO_XX(what) \ what(char*, "STRING") \ what(NanoTimeArgument, NANOTIME) \ what(jlong, "JLONG") ... etc then #define XX(TYPE, NAME) \ if (strcmp(type, NAME) == 0) { \ DCmdArgument* argument = new DCmdArgument(name, desc, NAME, mandatory, mandatory, default_value); \ } ALL_TYPES_DO_XX(XX) #undef XX ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685411741 From cjplummer at openjdk.org Sat Jul 20 18:03:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 20 Jul 2024 18:03:33 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v4] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 06:33:09 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20237#pullrequestreview-2190034803 From jsjolen at openjdk.org Sun Jul 21 08:58:35 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sun, 21 Jul 2024 08:58:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 20 Jul 2024 12:06:33 GMT, Thomas Stuefe wrote: >> On top: We hug the `*`s next to the type in Hotspot, not next to the var name. So `DCmdArgument* argument`. This is something to check for all new code. >> >> Pre-existing: The indentation of the if-block is wrong. >> >> Also, @SoniaZaldana, would you mind changing the code to this (does not include your change), the repetition just made me cringe ?. >> >> ```c++ >> DCmdArgument* argument = nullptr; >> if (strcmp(type, "STRING") == 0) { >> argument = new DCmdArgument(name, desc, "STRING", mandatory, default_value); >> } else if (strcmp(type, "NANOTIME") == 0) { >> DCmdArgument* argument = new DCmdArgument(name, desc, "NANOTIME", mandatory, default_value); >> } else if (strcmp(type, "JLONG") == 0) { >> DCmdArgument* argument = new DCmdArgument(name, desc, "JLONG", mandatory, default_value); >> } else if (strcmp(type, "BOOLEAN") == 0) { >> DCmdArgument* argument = new DCmdArgument(name, desc, "BOOLEAN", mandatory, default_value); >> } else if (strcmp(type, "MEMORYSIZE") == 0) { >> DCmdArgument* argument = new DCmdArgument(name, desc, "MEMORY SIZE", mandatory, default_value); >> } else if (strcmp(type, "STRINGARRAY") == 0) { >> DCmdArgument* argument = new DCmdArgument(name, desc, "STRING SET", mandatory); >> } >> >> if (argument != nullptr) { >> if (isarg) { >> parser->add_dcmd_argument(argument); >> } else { >> parser->add_dcmd_option(argument); >> } >> } > > @jdksjolen > >> Also, @SoniaZaldana, would you mind changing the code to this > > Even simpler (did not test, but you get my drift): > > > #define ALL_TYPES_DO_XX(what) \ > what(char*, "STRING") \ > what(NanoTimeArgument, NANOTIME) \ > what(jlong, "JLONG") > ... etc > > then > > > #define XX(TYPE, NAME) \ > if (strcmp(type, NAME) == 0) { \ > DCmdArgument* argument = new DCmdArgument(name, desc, NAME, mandatory, mandatory, default_value); \ > } > ALL_TYPES_DO_XX(XX) > #undef XX > > > ;-) Sonia, my bad if you already know this stuff but since it's fairly esoteric knowledge nowadays I'd like to help you out in advance: Thomas is proposing the usage of a X macro https://en.wikipedia.org/wiki/X_macro These can be found throughout Hotspot, you can find an example definition and usage in `logTag.hpp` and `logTag.cpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685688287 From stuefe at openjdk.org Sun Jul 21 10:11:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 21 Jul 2024 10:11:31 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sun, 21 Jul 2024 08:55:35 GMT, Johan Sj?len wrote: >> @jdksjolen >> >>> Also, @SoniaZaldana, would you mind changing the code to this >> >> Even simpler (did not test, but you get my drift): >> >> >> #define ALL_TYPES_DO_XX(what) \ >> what(char*, "STRING") \ >> what(NanoTimeArgument, NANOTIME) \ >> what(jlong, "JLONG") >> ... etc >> >> then >> >> >> #define XX(TYPE, NAME) \ >> if (strcmp(type, NAME) == 0) { \ >> DCmdArgument* argument = new DCmdArgument(name, desc, NAME, mandatory, mandatory, default_value); \ >> } >> ALL_TYPES_DO_XX(XX) >> #undef XX >> >> >> ;-) > > Sonia, my bad if you already know this stuff but since it's fairly esoteric knowledge nowadays I'd like to help you out in advance: Thomas is proposing the usage of a X macro https://en.wikipedia.org/wiki/X_macro > > These can be found throughout Hotspot, you can find an example definition and usage in `logTag.hpp` and `logTag.cpp`. @SoniaZaldana Note that this is very much optional. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685701779 From dholmes at openjdk.org Sun Jul 21 23:09:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Jul 2024 23:09:34 GMT Subject: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 08:26:51 GMT, Alan Bateman wrote: >> Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. >> >> This also picks up the unpublished changes to java.1 from: >> >> - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags >> - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC >> >> And a typo crept in to java.1 from: >> - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal >> >> This also picks up the unpublished change to keytool.1 from: >> >> - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints >> >> This also picks up the unpublished change to javadoc.1 from: >> >> - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class >> >> and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: >> >> - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments >> - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments >> >> The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). >> >> Thanks. > > Thanks for the tireless effort to update the man pages at the end of each release. Thanks for the reviews @AlanBateman and @irisclark ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20248#issuecomment-2241805932 From dholmes at openjdk.org Sun Jul 21 23:09:35 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Jul 2024 23:09:35 GMT Subject: [jdk23] Integrated: 8325280: Update troff manpages in JDK 23 before RC In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. > > This also picks up the unpublished changes to java.1 from: > > - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-8324836): Update Manpage for obsoletion of RAMFraction flags > - [JDK-8330807](https://bugs.openjdk.org/browse/JDK-8330807): Update Manpage for obsoletion of ScavengeBeforeFullGC > > And a typo crept in to java.1 from: > - [JDK-8331670](https://bugs.openjdk.org/browse/JDK-8331670): Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal > > This also picks up the unpublished change to keytool.1 from: > > - [JDK-8284500](https://bugs.openjdk.org/browse/JDK-8284500): Typo in Supported Named Extensions - BasicContraints > > This also picks up the unpublished change to javadoc.1 from: > > - [JDK-8324342](https://bugs.openjdk.org/browse/JDK-8324342): Doclet should default @since for a nested class to that of its enclosing class > > and some formatting changes (unclear why - perhaps pandoc version) from the combined changeset for: > > - [JDK-8298405](https://bugs.openjdk.org/browse/JDK-8298405): Implement JEP 467: Markdown Documentation Comments > - [JDK-8329296](https://bugs.openjdk.org/browse/JDK-8329296): Update Elements for '///' documentation comments > > The javac.1 file has its copyright year reverted to match what is in the source file (which should have been updated but wasn't). > > Thanks. This pull request has now been integrated. Changeset: 5473e9e4 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/5473e9e488c8fc7d99ea9d97fd0e7dd212636546 Stats: 142 lines in 28 files changed: 51 ins; 52 del; 39 mod 8325280: Update troff manpages in JDK 23 before RC Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.org/jdk/pull/20248 From dholmes at openjdk.org Mon Jul 22 01:23:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Jul 2024 01:23:39 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 20 Jul 2024 07:50:46 GMT, Thomas Stuefe wrote: >> Yes. In this file, other commands use `fatal` only where reading the hard-coded default values - in the various `init_...` functions. Hard-coded values should be valid, obviously, otherwise the JVM developer messed up. Other values are passed in by the end user via jcmd and should not crash the JVM. > > I see the prevalent way to deal with runtime parse errors is to throw a java exception. That exception later is caught in the command processing loop at the entrance of the attach listener thread. > > So, @SoniaZaldana, I would do this here too - when in Rome... > > But is this not unnecessarily complex? It requires the AttachListener to be a java thread when in fact it does need no java - we just misuse java exception handling as a way to pass error information up the stack, with the simple ultimate goal of writing error information into the outputStream to be sent to the caller. We might just as well pass the outputStream* to the parse_xxx functions as third argument, and write directly and return some error code. This would make the attach listener thread a lot less dependent on Java and more robust - at least for jcmds that don't need Java (which jcmds need java?). > > After all, the attach listener is supposed to be super robust and always work even if the JVM misbehaves. @dholmes-ora @lmesnik what do you guys think, should we change that? (obviously in a different RFE) If the attach listener thread doesn't actually need to be a Java thread then you could look into changing that. Not sure it would really buy us that much in terms of added robustness though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685861533 From dholmes at openjdk.org Mon Jul 22 01:27:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Jul 2024 01:27:42 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <63Fx1KzzGDy5E1pMf0HOb3P9o6gD6Rtps3YJYu-MLyY=.539c62f1-c36a-4fe4-8c57-ab44d932d4cb@github.com> On Fri, 19 Jul 2024 14:07:12 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Missing copyright header update src/hotspot/share/services/diagnosticArgument.cpp line 361: > 359: void DCmdArgument::parse_value(const char *str, size_t len, > 360: TRAPS) { > 361: if (str == NULL) { s/NULL/nullptr src/hotspot/share/services/diagnosticArgument.cpp line 372: > 370: > 371: template <> void DCmdArgument::init_value(TRAPS) { > 372: if (has_default() && _default_string != NULL) { s/NULL/nullptr ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685862082 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1685862613 From dlunden at openjdk.org Mon Jul 22 07:48:34 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Mon, 22 Jul 2024 07:48:34 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v4] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 06:33:09 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thanks for the reviews. Please sponsor! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2242302686 From duke at openjdk.org Mon Jul 22 07:48:34 2024 From: duke at openjdk.org (duke) Date: Mon, 22 Jul 2024 07:48:34 GMT Subject: RFR: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp [v4] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 06:33:09 GMT, Daniel Lund?n wrote: >> We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. >> >> ### Changeset >> >> - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. > > Daniel Lund?n has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright @dlunde Your change (at version 1ab05291f81b3013b7fb586a77b06d9eeec69d6d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20237#issuecomment-2242304340 From szaldana at openjdk.org Mon Jul 22 13:45:49 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 13:45:49 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: > Hi all, > > This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Adding comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20257/files - new: https://git.openjdk.org/jdk/pull/20257/files/6129d87c..237f751a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20257/head:pull/20257 PR: https://git.openjdk.org/jdk/pull/20257 From kevinw at openjdk.org Mon Jul 22 14:32:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 14:32:33 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 13:45:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding comment src/hotspot/share/code/codeCache.cpp line 1804: > 1802: fileStream fs(filename, "w"); > 1803: if (!fs.is_open()) { > 1804: st->print_cr("Failed to create %s for perf map", filename); Hi -- as this used to be "log_warning" and print something like: [1129077.636s][warning][codecache] Failed to create /x for perf map ..it should probably say: Warning: Failed to...etc... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1686652944 From kevinw at openjdk.org Mon Jul 22 14:35:32 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 14:35:32 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 13:45:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding comment Looks good. Yes the DCmds in diagnosticCommand.cpp tend to use outputStream* output (or out) as a param, this may help make it more obvious what the stream is for. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20257#issuecomment-2243113330 From kevinw at openjdk.org Mon Jul 22 14:43:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 14:43:33 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 13:45:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding comment test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 124: > 122: OutputAnalyzer output = new JMXExecutor().execute("Compiler.perfmap %s".formatted(path)); > 123: output.shouldContain("Failed to create nonexistent/%s for perf map".formatted(test_dir)); > 124: output.shouldNotHaveExitValue(0); I'm curious if this exit value check works, as jcmd failures like this show "Command executed successfully" and return 0 for success. These compiler tests have chosen JMXExecutor and PidJcmdExecutor which might be relevant. Interested to know if JMXExecutor returns a non-zero exit value for this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1686674484 From dlunden at openjdk.org Mon Jul 22 14:44:35 2024 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Mon, 22 Jul 2024 14:44:35 GMT Subject: Integrated: 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 15:00:41 GMT, Daniel Lund?n wrote: > We are seeing quite a few timeouts for `serviceability/sa/ClhsdbDumpheap.java` running with -Xcomp in testing, possibly related to [JDK-8324241](https://bugs.openjdk.org/browse/JDK-8324241). We should disable running `ClhsdbDumpheap.java` with -Xcomp, at least for now. > > ### Changeset > > - Add `@requires vm.compMode != "Xcomp"` to `ClhsdbDumpheap.java`. This pull request has now been integrated. Changeset: 0725eb1d Author: Daniel Lund?n URL: https://git.openjdk.org/jdk/commit/0725eb1df2357bb0489e2521d96bb424fc233406 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8336753: Don't run serviceability/sa/ClhsdbDumpheap.java with -Xcomp Reviewed-by: cjplummer, kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/20237 From kevinw at openjdk.org Mon Jul 22 15:13:08 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 15:13:08 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v3] In-Reply-To: References: Message-ID: <6MQoAgyarrp14OwfqedX6b1oGAhQxn9J29khxQQAw7E=.7db1f899-4425-474b-bfd6-8913ad9cc8a2@github.com> > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. Kevin Walls 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 four additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8332551_MemoryNotificationInfo_from001 - formatting - update - 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20146/files - new: https://git.openjdk.org/jdk/pull/20146/files/a6965231..bcf6b450 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20146&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20146&range=01-02 Stats: 8630 lines in 367 files changed: 5704 ins; 1620 del; 1306 mod Patch: https://git.openjdk.org/jdk/pull/20146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20146/head:pull/20146 PR: https://git.openjdk.org/jdk/pull/20146 From szaldana at openjdk.org Mon Jul 22 15:36:47 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 15:36:47 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v4] In-Reply-To: References: Message-ID: > Hi all, > > This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Updating warning message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20257/files - new: https://git.openjdk.org/jdk/pull/20257/files/237f751a..a2e46173 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20257&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20257/head:pull/20257 PR: https://git.openjdk.org/jdk/pull/20257 From szaldana at openjdk.org Mon Jul 22 15:36:47 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 15:36:47 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 14:41:16 GMT, Kevin Walls wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding comment > > test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 124: > >> 122: OutputAnalyzer output = new JMXExecutor().execute("Compiler.perfmap %s".formatted(path)); >> 123: output.shouldContain("Failed to create nonexistent/%s for perf map".formatted(test_dir)); >> 124: output.shouldNotHaveExitValue(0); > > I'm curious if this exit value check works, as jcmd failures like this show "Command executed successfully" and return 0 for success. > These compiler tests have chosen JMXExecutor and PidJcmdExecutor which might be relevant. Interested to know if JMXExecutor returns a non-zero exit value for this? Hi Kevin, Yes, I noticed the test was exiting with a non-zero value when I was testing. After giving it a bit more thought, that check is not the main purpose of the test and I'm not entirely sure why the JMXExecutor behaves that way. I'll just remove the exit value check to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1686750734 From kevinw at openjdk.org Mon Jul 22 16:34:32 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 16:34:32 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 15:33:27 GMT, Sonia Zaldana Calles wrote: >> test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 124: >> >>> 122: OutputAnalyzer output = new JMXExecutor().execute("Compiler.perfmap %s".formatted(path)); >>> 123: output.shouldContain("Failed to create nonexistent/%s for perf map".formatted(test_dir)); >>> 124: output.shouldNotHaveExitValue(0); >> >> I'm curious if this exit value check works, as jcmd failures like this show "Command executed successfully" and return 0 for success. >> These compiler tests have chosen JMXExecutor and PidJcmdExecutor which might be relevant. Interested to know if JMXExecutor returns a non-zero exit value for this? > > Hi Kevin, > > Yes, I noticed the test was exiting with a non-zero value when I was testing. After giving it a bit more thought, that check is not the main purpose of the test and I'm not entirely sure why the JMXExecutor behaves that way. I'll just remove the exit value check to avoid confusion. I think it was returning an "exit value" of -1, the test/lib/jdk/test/lib/process/OutputBuffer.java default. JMXExecutor doesn't set one as there isn't an exit code... That could be clearer, actually there must be various issues in that area. But yes just don't check exit code for a JMX Executor, and jcmd would return zero but we don't want to embed that as a requirement, it's really a failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1686829542 From kevinw at openjdk.org Mon Jul 22 16:40:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 16:40:34 GMT Subject: RFR: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out [v3] In-Reply-To: <6MQoAgyarrp14OwfqedX6b1oGAhQxn9J29khxQQAw7E=.7db1f899-4425-474b-bfd6-8913ad9cc8a2@github.com> References: <6MQoAgyarrp14OwfqedX6b1oGAhQxn9J29khxQQAw7E=.7db1f899-4425-474b-bfd6-8913ad9cc8a2@github.com> Message-ID: On Mon, 22 Jul 2024 15:13:08 GMT, Kevin Walls wrote: >> Short version: >> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" >> >> Make additional typo fixes and tidyups while here, it's just shocking. >> >> TestDescription.java contains the test definition, so the "requires" goes there, with a comment. >> >> Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. > > Kevin Walls 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 four additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8332551_MemoryNotificationInfo_from001 > - formatting > - update > - 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20146#issuecomment-2243378095 From kevinw at openjdk.org Mon Jul 22 16:43:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Jul 2024 16:43:36 GMT Subject: Integrated: 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 21:08:20 GMT, Kevin Walls wrote: > Short version: > Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp" > > Make additional typo fixes and tidyups while here, it's just shocking. > > TestDescription.java contains the test definition, so the "requires" goes there, with a comment. > > Updates to from001.java are typos and clarifications, and a changed loop with a poll on a queue rather than block forever. This pull request has now been integrated. Changeset: 7ea77305 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/7ea773056433c467dbd321a0a063f4789552ef89 Stats: 68 lines in 2 files changed: 33 ins; 1 del; 34 mod 8332551: Test vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescription.java timed out Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/20146 From sgehwolf at openjdk.org Mon Jul 22 17:18:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Jul 2024 17:18:09 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:56:00 GMT, Severin Gehwolf wrote: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [ ] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Note for reviewers. I'll be away until early August, so my responses might be delayed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2243438170 From sgehwolf at openjdk.org Mon Jul 22 17:18:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Jul 2024 17:18:09 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics Message-ID: Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). This patch addresses this issue by: 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. Thoughts? Testing: - [ ] GHA - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems - [x] Some manual testing using systemd slices ------------- Depends on: https://git.openjdk.org/jdk/pull/17198 Commit messages: - 8336881: [Linux] Support for hierarchical limits for Metrics Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336881 Stats: 1511 lines in 24 files changed: 1260 ins; 152 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From cjplummer at openjdk.org Mon Jul 22 17:57:30 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 17:57:30 GMT Subject: RFR: 8334145: missing from vm_memory_map_.txt in System.dump_map help text In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote: > Fix issue with `` argument. Can I get a 2nd review please? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20246#issuecomment-2243506993 From stuefe at openjdk.org Mon Jul 22 18:17:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Jul 2024 18:17:31 GMT Subject: RFR: 8334145: missing from vm_memory_map_.txt in System.dump_map help text In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote: > Fix issue with `` argument. +1 ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20246#pullrequestreview-2192244620 From amenkov at openjdk.org Mon Jul 22 18:22:31 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 22 Jul 2024 18:22:31 GMT Subject: RFR: 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep In-Reply-To: References: Message-ID: <_d9v9WeuvFgK19NhmxvRmIrIWT8LygfVQE7z9m3Swqo=.994d7fd9-3a56-4571-b9f9-bdeda37efac4@github.com> On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote: > The test sometimes fails because the InterruptException doesn't arrive during the 100ms that the thread sleeps. My suspicion is that the interrupt is being delayed for some external reason, like temporary load on the host. I'm bumping the sleep period to 10s to hopefully avoid such an issue. This won't make the test run any slower when it passes, but will make it slower (by about 10 seconds) when it fails due to waiting longer for the InterruptException to never arrive, assuming it still might fail for this reason. > > I tested by running the InterruptHangTest locally. TBD I will run all of con/sun/jdi on all supported platforms. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20263#pullrequestreview-2192261257 From cjplummer at openjdk.org Mon Jul 22 18:41:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 18:41:31 GMT Subject: RFR: 8334145: missing from vm_memory_map_.txt in System.dump_map help text In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote: > Fix issue with `` argument. Thanks David and Thomas! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20246#issuecomment-2243584280 From cjplummer at openjdk.org Mon Jul 22 19:00:36 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 19:00:36 GMT Subject: Integrated: 8334145: missing from vm_memory_map_.txt in System.dump_map help text In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:44:16 GMT, Chris Plummer wrote: > Fix issue with `` argument. This pull request has now been integrated. Changeset: b144910e Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/b144910ebb74be5a12dae57263f2a93452535f02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8334145: missing from vm_memory_map_.txt in System.dump_map help text Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/20246 From cjplummer at openjdk.org Mon Jul 22 19:31:35 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 19:31:35 GMT Subject: RFR: 8328866: Add raw monitor rank support to the debug agent. [v8] In-Reply-To: References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: On Fri, 17 May 2024 19:32:31 GMT, Chris Plummer wrote: >> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work >> >> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process. >> >> Tested with the following on all supported platforms and with virtual threads: >> >> com/sun/jdi >> vmTestbase/nsk/jdi >> vmTestbase/nsk/jdb >> vmTestbase/nsk/jdwp >> >> Still need to run tier2 and tier5. >> >> Details of the changes follow in the first comment. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix a couple of minor typos in comments. Keep alive. I'll be continuing work on this soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2243666674 From cjplummer at openjdk.org Mon Jul 22 19:36:35 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 19:36:35 GMT Subject: RFR: 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote: > The test sometimes fails because the InterruptException doesn't arrive during the 100ms that the thread sleeps. My suspicion is that the interrupt is being delayed for some external reason, like temporary load on the host. I'm bumping the sleep period to 10s to hopefully avoid such an issue. This won't make the test run any slower when it passes, but will make it slower (by about 10 seconds) when it fails due to waiting longer for the InterruptException to never arrive, assuming it still might fail for this reason. > > I tested by running the InterruptHangTest locally. TBD I will run all of con/sun/jdi on all supported platforms. Thank you Leonid and Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20263#issuecomment-2243672933 From cjplummer at openjdk.org Mon Jul 22 19:36:36 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 19:36:36 GMT Subject: Integrated: 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep In-Reply-To: References: Message-ID: <4f6kEB9ssuRYkKBehjQdvyK5ne81TdCJD31PXp9lRo0=.72eb93f7-486d-40a6-9d58-b2b82dbeab54@github.com> On Fri, 19 Jul 2024 18:41:10 GMT, Chris Plummer wrote: > The test sometimes fails because the InterruptException doesn't arrive during the 100ms that the thread sleeps. My suspicion is that the interrupt is being delayed for some external reason, like temporary load on the host. I'm bumping the sleep period to 10s to hopefully avoid such an issue. This won't make the test run any slower when it passes, but will make it slower (by about 10 seconds) when it fails due to waiting longer for the InterruptException to never arrive, assuming it still might fail for this reason. > > I tested by running the InterruptHangTest locally. TBD I will run all of con/sun/jdi on all supported platforms. This pull request has now been integrated. Changeset: ed649944 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/ed6499446dadc339599271a282ceca4a52dbeed4 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8333391: Test com/sun/jdi/InterruptHangTest.java failed: Thread was never interrupted during sleep Reviewed-by: lmesnik, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/20263 From szaldana at openjdk.org Mon Jul 22 19:49:08 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 19:49:08 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v6] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision: - Fixing memory leak - Fixing pointer style, s/NULL/nullptr, and exception - Cleaning up parserTests.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/cdf1d457..801fc582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=04-05 Stats: 78 lines in 4 files changed: 9 ins; 16 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Mon Jul 22 20:03:08 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 20:03:08 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v7] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <5UHSCkGbA7jXwwEfE8ou0LzvPd5flc7M9ZwbNhZFFvM=.c677a49b-c98c-42c9-81df-b366379aefa9@github.com> > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Error messaging format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/801fc582..517db0cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Mon Jul 22 20:06:33 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 20:06:33 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <_frxtxQ56OXre5svEw_F8AOS7t-bOT0wSP1rcIh_hOI=.b8544cfb-66bd-4431-a63c-0599b2a38f08@github.com> On Sun, 21 Jul 2024 10:08:38 GMT, Thomas Stuefe wrote: >> Sonia, my bad if you already know this stuff but since it's fairly esoteric knowledge nowadays I'd like to help you out in advance: Thomas is proposing the usage of a X macro https://en.wikipedia.org/wiki/X_macro >> >> These can be found throughout Hotspot, you can find an example definition and usage in `logTag.hpp` and `logTag.cpp`. > > @SoniaZaldana Note that this is very much optional. Hi folks, thanks for the pointers! I wasn't familiar with X macros and after some time toying around with them, I'm sad to report that I am not a fan (yet!). I implemented it and ended up breaking part of the tests. I quickly realized that debugging these is a bit harder for less experienced c++ developers (like myself). So, just wanted to note: - I cleaned up the indentation in this function as it was all wrong. - I didn't get rid of the repetition. Tried to but quickly realized we can't pull the DCmdArgument out of the if statements as they're different types. And note to self, to keep reviewing X macros because they did shorten the code a lot when I implemented them. Perhaps I'll give it another go in a different RFE. Sorry it's not what either of you hoped for! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1687080108 From szaldana at openjdk.org Mon Jul 22 20:06:34 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 20:06:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <5-itK2a-qgShmcLpo2Dvj1OUds2U1PF9uqgi8eO5Odk=.fc97e659-13d7-4c5e-800a-16ebdcf3e809@github.com> On Sat, 20 Jul 2024 08:02:34 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/diagnosticArgument.hpp line 66: >> >>> 64: public: >>> 65: char *_name; >>> 66: }; >> >> Something is off about this. What is the lifetime of this object? >> >> You don't free it. Running a command in a loop will consume C-heap (you can check this with NMT: `jcmd VM.native_memory baseline`, then run a command 100 times, then `jcmd VM.native_memory summary.diff` will show you the leak in mtInternal. >> >> I would probably just inline the string. E.g. >> >> >> struct FileArgument { >> char name[max name len] >> }; >> >> >> FileArguments sits as member inside DCmdArgument. DCmdArgument or DCmdArgumentWithParser sits as member in the various XXXDCmd classes. >> >> Those are created in DCmdFactory::create_local_DCmd(). Which is what, a static global list? So we only have one global XXXDCmd object instance per command, but for each command invocation re-parse the argument values? What a weird concept. >> >> Man, this coding is way too convoluted for a little parser engine :( >> >> But anyway, inlining the filename array into FileArgument should be probably fine from a size standpoint. I would, however, not use JVM_MAXPATHLEN or anything that depends ultimately on PATH_MAX from system headers. We don't want the object to consume e.g. an MB if some crazy platform defines PATH_MAX as 1MB. Therefore I would use e.g. 1024 as limit for the path name. >> >> (Note that PATH_MAX is an illusion anyway, there is never a guarantee that a path is smaller than that limit... See this good article: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html) > > Note that the reason for the leak is probably the fact that you don't clear old values on parse_value. See e.g. how char* does it. However, since you allocate with a constant size anyway, the buffer size never changes, you could just as well either follow my advice above (inlining), or just re-use the existing pointer. Hi Thomas, Yes - this was an oversight on my end. I was not directly calling the `destroy_value()` function. I tried to follow more closely what?s done for `char*`, as I like the consistency throughout. I did a quick check and I don?t see any more leaks with NMT. Does the new change make sense to you as well? Thank you for the feedback! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1687081245 From szaldana at openjdk.org Mon Jul 22 20:08:32 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 22 Jul 2024 20:08:32 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:31:32 GMT, Kevin Walls wrote: > I think it was returning an "exit value" of -1, the test/lib/jdk/test/lib/process/OutputBuffer.java default. Correct, that was the exit value. > But yes just don't check exit code for a JMX Executor, and jcmd would return zero but we don't want to embed that as a requirement, it's really a failure. Agreed. I removed the exit status check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20257#discussion_r1687083247 From cjplummer at openjdk.org Mon Jul 22 20:36:41 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 20:36:41 GMT Subject: RFR: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames Message-ID: Fix deadlock with debug agent callbackLock. Details in first comment. Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. ------------- Commit messages: - Fix deadlock with callbackLock. Changes: https://git.openjdk.org/jdk/pull/20282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332738 Stats: 44 lines in 5 files changed: 29 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20282/head:pull/20282 PR: https://git.openjdk.org/jdk/pull/20282 From cjplummer at openjdk.org Mon Jul 22 20:36:41 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Jul 2024 20:36:41 GMT Subject: RFR: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote: > Fix deadlock with debug agent callbackLock. Details in first comment. > > Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. There is a deadlock with the callbackLock that currently happens with my work in progress for [JDK-8328866](https://bugs.openjdk.org/browse/JDK-8328866) (ranked monitor support), but it could potentially happen without it. The only thing that saves the current implementation from the deadlock is the fact that RawMonitorExit releases the monitor before doing a self suspend, and there is nothing else done while holding the callbackLock that might allow for a self suspend. However, with [JDK-8328866](https://bugs.openjdk.org/browse/JDK-8328866) there is an opportunity for a self suspend, which is why I started to see callbackLock deadlocks with that work. The description of the CR contains details on the root cause of this bug. The main fix for this bug is acquiring the callbackLock in getLocks() to avoid any thread from being suspended while holding the callbackLock. I also fixed some lock order issues that were discovered while working on JDK-8328866. Some of these were necessary to do now, and all will be needed for JDK-8328866, so making the change here will help avoid conflicts. In stepControl_beginStep() I also added the callbackLock to the list of locks acquired. This is needed to maintain proper lock ordering because threadControl_suspendThread() will be called, which calls getLocks(). In invoker_completeInvokeRequest() I also added the callbackLock to the list of locks acquired. This is needed to maintain proper lock ordering because threadControl_suspendThread() or threadControl_suspendAll() will be called, which both call getLocks(). I also added acquiring the stepLock. This is needed because we already acquire the invokeLock here, and getLocks() acquires the invokeLock after the stepLock, so we must do the same here in order to maintain lock ordering. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20282#issuecomment-2243765072 From lmesnik at openjdk.org Mon Jul 22 21:49:31 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 22 Jul 2024 21:49:31 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v4] In-Reply-To: References: Message-ID: <_w6qRLOoFJVbJ29HZIxuwJy-ikNOKsLLXfdgUmPQ-6M=.ea3356ed-e677-4aa9-8782-debc015b0084@github.com> On Mon, 22 Jul 2024 15:36:47 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating warning message Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20257#pullrequestreview-2192606124 From stuefe at openjdk.org Tue Jul 23 06:48:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Jul 2024 06:48:31 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v4] In-Reply-To: References: Message-ID: <8VD-XmtZQBI9KdQVZfZIRjvQSgyAkXKy4TXK7jdLBa0=.07cc90b9-d704-445a-b4a8-f100e611d0aa@github.com> On Mon, 22 Jul 2024 15:36:47 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating warning message Looks good ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20257#pullrequestreview-2193108607 From sspitsyn at openjdk.org Tue Jul 23 07:03:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Jul 2024 07:03:57 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be Message-ID: The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw()` function. The assert is not fully correct as it does not account for an unexpected scenario. Thanks to Patricio for reproducing this failure and identifying the root cause: > The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). The fix corrects the assert to account for the `thread->jni_monitor_count()`. Also, the fix includes the test tweak described above which makes this failure always reproducible. Testing: - Ran the test `GetOwnedMonitorInfoTest.java` locally - Mach5 tiers 1-6 are passed ------------- Commit messages: - 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be Changes: https://git.openjdk.org/jdk/pull/20294/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334085 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20294/head:pull/20294 PR: https://git.openjdk.org/jdk/pull/20294 From sspitsyn at openjdk.org Tue Jul 23 07:25:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Jul 2024 07:25:44 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: > The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. > > Thanks to Patricio for reproducing this failure and identifying the root cause: >> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). > The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). > > The fix corrects the assert to account for the `thread->jni_monitor_count()`. > Question: Is the same scenario possible for non-JNI monitors as well? > Also, the fix includes the test tweak described above which makes this failure always reproducible. > > Testing: > - Ran the test `GetOwnedMonitorInfoTest.java` locally > - Mach5 tiers 1-6 are passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: comment tweak ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20294/files - new: https://git.openjdk.org/jdk/pull/20294/files/5dca26f8..9c10c555 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20294/head:pull/20294 PR: https://git.openjdk.org/jdk/pull/20294 From kevinw at openjdk.org Tue Jul 23 08:03:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Jul 2024 08:03:38 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v4] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 15:36:47 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating warning message Marked as reviewed by kevinw (Reviewer). Yes looks good. I only waited in case you were changing "outputStream* st" to be called out or output, to address Thomas' comment. (I notice now the added comment.) ------------- PR Review: https://git.openjdk.org/jdk/pull/20257#pullrequestreview-2193261838 PR Comment: https://git.openjdk.org/jdk/pull/20257#issuecomment-2244523438 From kevinw at openjdk.org Tue Jul 23 10:18:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Jul 2024 10:18:38 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: <4woQIJpyoBiLAqvN91yvDmPnC3kg6UyWqrYg9RzkHxk=.fd3a39f8-3101-4b46-95cc-fb14cef83312@github.com> On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > Alan Bateman 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 eight additional commits since the last revision: > > - Merge > - Fix typo in comment, missing copyright update, test nits > - Merge > - Drop JLA updates for this update > - Merge > - Merge > - Update copyright headers > - Initial commit The JMX/ThreadMXBean test updates look good to me. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2193566771 From jsjolen at openjdk.org Tue Jul 23 12:11:34 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 23 Jul 2024 12:11:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v5] In-Reply-To: <_frxtxQ56OXre5svEw_F8AOS7t-bOT0wSP1rcIh_hOI=.b8544cfb-66bd-4431-a63c-0599b2a38f08@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <_frxtxQ56OXre5svEw_F8AOS7t-bOT0wSP1rcIh_hOI=.b8544cfb-66bd-4431-a63c-0599b2a38f08@github.com> Message-ID: On Mon, 22 Jul 2024 20:02:40 GMT, Sonia Zaldana Calles wrote: >> @SoniaZaldana Note that this is very much optional. > > Hi folks, thanks for the pointers! I wasn't familiar with X macros and after some time toying around with them, I'm sad to report that I am not a fan (yet!). > > I implemented it and ended up breaking part of the tests. I quickly realized that debugging these is a bit harder for less experienced c++ developers (like myself). > > So, just wanted to note: > - I cleaned up the indentation in this function as it was all wrong. > - I didn't get rid of the repetition. Tried to but quickly realized we can't pull the DCmdArgument out of the if statements as they're different types. > > And note to self, to keep reviewing X macros because they did shorten the code a lot when I implemented them. Perhaps I'll give it another go in a different RFE. > > Sorry it's not what either of you hoped for! That's fine, thanks for having a go! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1687949210 From coleenp at openjdk.org Tue Jul 23 12:37:42 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 12:37:42 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> On Mon, 15 Jul 2024 00:44:02 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 1090: >> >>> 1088: >>> 1089: // Step 2 >>> 1090: // If we were to use wait() instead of waitUninterruptibly() then >> >> This is a nice correction (even though, the actual call below is wait_uninterruptibly() ;-) ), but seems totally unrelated. > > I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 git backout restored the old wrong comment. We should fix this separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1687985648 From mbaesken at openjdk.org Tue Jul 23 13:22:52 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Jul 2024 13:22:52 GMT Subject: Withdrawn: 8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 11:57:04 GMT, Matthias Baesken wrote: > Currently jcmd command GC.heap_dump only works with an additionally provided file name. > Syntax : GC.heap_dump [options] > > In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the is optional. > In case the filename is NOT set, we take the HeapDumpPath (file or directory); > > new syntax : > GC.heap_dump [options] .. has precedence over second option > GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set > > This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18190 From duke at openjdk.org Tue Jul 23 13:28:36 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jul 2024 13:28:36 GMT Subject: RFR: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() [v4] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 15:36:47 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating warning message @SoniaZaldana Your change (at version a2e46173e7d260f8fbc1a9372090ea5867a65a29) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20257#issuecomment-2245252290 From ayang at openjdk.org Tue Jul 23 14:18:58 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Jul 2024 14:18:58 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate Message-ID: Simple obsoleting a Parallel GC product flag. ------------- Commit messages: - pgc-obsolete-base-footprint Changes: https://git.openjdk.org/jdk/pull/20299/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20299&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337027 Stats: 28 lines in 7 files changed: 0 ins; 25 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20299/head:pull/20299 PR: https://git.openjdk.org/jdk/pull/20299 From szaldana at openjdk.org Tue Jul 23 15:52:37 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 23 Jul 2024 15:52:37 GMT Subject: Integrated: 8327054: DiagnosticCommand Compiler.perfmap does not log on output() In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:07:39 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This is a small patch to address [8327054](https://bugs.openjdk.org/browse/JDK-8327054) making `CodeCache::write_perf_map` aware of which output stream errors and warning message should be going to. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia This pull request has now been integrated. Changeset: 8e1f17e3 Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/8e1f17e351bc7949b318a0542a4a4cb30ead5a97 Stats: 18 lines in 5 files changed: 12 ins; 0 del; 6 mod 8327054: DiagnosticCommand Compiler.perfmap does not log on output() Reviewed-by: lmesnik, stuefe, kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/20257 From stuefe at openjdk.org Tue Jul 23 15:59:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Jul 2024 15:59:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v7] In-Reply-To: <5UHSCkGbA7jXwwEfE8ou0LzvPd5flc7M9ZwbNhZFFvM=.c677a49b-c98c-42c9-81df-b366379aefa9@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <5UHSCkGbA7jXwwEfE8ou0LzvPd5flc7M9ZwbNhZFFvM=.c677a49b-c98c-42c9-81df-b366379aefa9@github.com> Message-ID: On Mon, 22 Jul 2024 20:03:08 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Error messaging format Slowly getting there... :) src/hotspot/share/prims/wbtestmethods/parserTests.cpp line 79: > 77: DCmdArgument* argument = new DCmdArgument( > 78: name, desc, > 79: "STRING", mandatory, default_value); I would revert all these style-only changes and just keep the functional one (addition of FileArgument handling). Let's keep this for a follow-up. src/hotspot/share/services/diagnosticArgument.cpp line 376: > 374: THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), error_msg.base()); > 375: } > 376: } The realloc here is a bit pointless since if `_value._name` is set, it already points to a buffer of size JVM_MAXPATHLEN. I would either one of these two: - either inline the buffer into FileArgument as I wrote earlier; no need to allocate or deallocate then. - or, in this function, allocate if _name is not null, use existing buffer otherwise src/hotspot/share/services/diagnosticCommand.cpp line 524: > 522: HeapDumper dumper(!_all.value() /* request GC if _all is false*/); > 523: dumper.dump(_filename.value()._name, output(), (int)level, _overwrite.value(), > 524: (uint)parallel); Please revert style-only changes, lets keep those for follow ups. src/hotspot/share/services/diagnosticCommand.cpp line 1195: > 1193: > 1194: void SystemDumpMapDCmd::execute(DCmdSource source, TRAPS) { > 1195: const char* name = _filename.value()._name; This direct access to the member inside _filename is a bit awkward. I would make the buffer private and give the class some getters and setters, possibly like this: class FileArgument { // private stuff public: const char* get() const { // return internal buffer } // returns true if parsing succeeded, false if not bool parse_value(const char* s, size_t len) { // call Arguments::copyexpand, target internal buffer, and return its return value } } ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2193132206 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1687527542 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1688310305 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1688264948 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1688316839 From pchilanomate at openjdk.org Tue Jul 23 16:21:34 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 23 Jul 2024 16:21:34 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 07:25:44 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > comment tweak Looks good to me, thanks Serguei! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20294#pullrequestreview-2194456828 From szaldana at openjdk.org Tue Jul 23 17:43:51 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 23 Jul 2024 17:43:51 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v8] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with three additional commits since the last revision: - Fixing formatting - Inlining buffer and making field private - Reverting to functional changes in parserTests.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/517db0cd..c898b1cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=06-07 Stats: 80 lines in 4 files changed: 16 ins; 9 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Tue Jul 23 17:57:04 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 23 Jul 2024 17:57:04 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge master - Fixing formatting - Inlining buffer and making field private - Reverting to functional changes in parserTests.cpp - Error messaging format - Fixing memory leak - Fixing pointer style, s/NULL/nullptr, and exception - Cleaning up parserTests.cpp - Missing copyright header update - Adding tests for file dcmd argument - ... and 5 more: https://git.openjdk.org/jdk/compare/2f2223d7...52ca557d ------------- Changes: https://git.openjdk.org/jdk/pull/20198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=08 Stats: 195 lines in 11 files changed: 154 ins; 19 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Tue Jul 23 18:12:32 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 23 Jul 2024 18:12:32 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <0FaB5dyzz0jaa0RETfdT4wcbS3jPg4QzIzj1s-pPWvw=.805a55dc-d141-482f-b6aa-e6c4fdfbb97d@github.com> Message-ID: <_dK88nL0aH7z6iBgH3_pwwFfCfzom8_I5xGJU5L0swo=.11562964-b22b-47c4-8dde-8c3bc42009b4@github.com> On Wed, 17 Jul 2024 14:21:05 GMT, Thomas Stuefe wrote: > * In all cases: please, in case of an error, don't THROW, don't do `warning`. Instead, just print to the `output()` of the DCmd. You want an error to appear to the user of the dcmd - so, to stdout or stderr of the jcmd process issuing the command. Not an exception in the target JVM process, nor a warning in the target JVM stderr stream FYI, I filed [JDK-8337047](https://bugs.openjdk.org/browse/JDK-8337047) to track this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2245923827 From coleenp at openjdk.org Tue Jul 23 19:09:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:43 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <1ivG4ii0OclIXn9-0Ihh4udD4WUu5Oe64ovWDY1xSJ4=.731721e8-806e-4e34-9ec0-3188b81f9f41@github.com> On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere. >> >> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code. >> >> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). >> >> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). >> >> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works. >> >> # Cleanups >> >> Cleaned up displaced header usage for: >> * BasicLock >> * Contains some Zero changes >> * Renames one exported JVMCI field >> * ObjectMonitor >> * Updates comments and tests consistencies >> >> # Refactoring >> >> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation. >> >> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. >> >> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._ >> >> # LightweightSynchronizer >> >> Working on adapting and incorporating the following section as a comment in the source code >> >> ## Fast Locking >> >> CAS on locking bits in markWord. >> 0b00 (Fast Locked) <--> 0b01 (Unlocked) >> >> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit. >> >> If 0b10 (Inflated) is observed or there is to... > > Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: > > - Remove try_read > - Add explicit to single parameter constructors > - Remove superfluous access specifier > - Remove unused include > - Update assert message OMCache::set_monitor > - Fix indentation > - Remove outdated comment LightweightSynchronizer::exit > - Remove logStream include > - Remove strange comment > - Fix javaThread include I have some suggestions that hopefully you can click on if you agree. Also, some comments. src/hotspot/share/runtime/lightweightSynchronizer.cpp line 67: > 65: } > 66: static void* allocate_node(void* context, size_t size, Value const& value) { > 67: reinterpret_cast(context)->inc_table_count(); Suggestion: reinterpret_cast(context)->inc_items_count(); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 71: > 69: }; > 70: static void free_node(void* context, void* memory, Value const& value) { > 71: reinterpret_cast(context)->dec_table_count(); Suggestion: reinterpret_cast(context)->dec_items_count(); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 125: > 123: }; > 124: > 125: void inc_table_count() { Suggestion: void inc_items_count() { src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126: > 124: > 125: void inc_table_count() { > 126: Atomic::inc(&_table_count); Suggestion: Atomic::inc(&_items_count); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 129: > 127: } > 128: > 129: void dec_table_count() { Suggestion: void dec_items_count() { src/hotspot/share/runtime/lightweightSynchronizer.cpp line 130: > 128: > 129: void dec_table_count() { > 130: Atomic::inc(&_table_count); Suggestion: Atomic::inc(&_items_count); src/hotspot/share/runtime/lightweightSynchronizer.cpp line 134: > 132: > 133: double get_load_factor() { > 134: return (double)_table_count/(double)_table_size; Suggestion: return (double)_items_count/(double)_table_size; ------------- PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2193868194 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688563846 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688563501 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565196 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565561 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688565947 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688566411 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688566752 From coleenp at openjdk.org Tue Jul 23 19:09:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:43 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> References: <7MDa4Z7FtvI5TG3rARV50PQckm3MSqOzBefku_lFwyc=.ead08ce2-1850-4803-a2eb-bd22cdcdd221@github.com> Message-ID: On Tue, 23 Jul 2024 12:34:45 GMT, Coleen Phillimore wrote: >> I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 > > git backout restored the old wrong comment. We should fix this separately. Suggestion: // If we were to use wait() instead of waitInterruptibly() then >> I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. >> >> `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. >> >> The current implementation is based on what we do for the StringTable and SymbolTable > > In the other tables, it's called _items_count and it determines the load_factor for triggering concurrent work. We should rename this field items_count to match, and also since it's consistent. Suggestion: volatile size_t _items_count; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1687990861 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688564267 From coleenp at openjdk.org Tue Jul 23 19:09:45 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:45 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6] In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 00:44:31 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/basicLock.cpp line 37: >> >>> 35: if (mon != nullptr) { >>> 36: mon->print_on(st); >>> 37: } >> >> I am not sure if we wanted to do this, but we know the owner, therefore we could also look-up the OM from the table, and print it. It wouldn't have all that much to do with the BasicLock, though. > > Yeah maybe it is unwanted. Not sure how we should treat these prints of the frames. My thinking was that there is something in the cache, print it. But maybe just treating it as some internal data, maybe print "monitor { }" or similar is better. It seems generally useful to print the monitor in the cache if it's there. I don't think we should do a table search here. I think this looks fine as it is, and might be helpful for debugging if it turns out to be the wrong monitor. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 80: >> >>> 78: >>> 79: ConcurrentTable* _table; >>> 80: volatile size_t _table_count; >> >> Looks like a misnomer to me. We only have one table, but we do have N entries/nodes. This is counted when new nodes are allocated or old nodes are freed. Consider renaming this to '_entry_count' or '_node_count'? I'm actually a bit surprised if ConcurrentHashTable doesn't already track this... > > I think I was thinking of the names as a prefix to refer to the `Count of the table` and `Size of the table`. And not the `Number of tables`. But I can see the confusion. > > `ConcurrentHashTable` tracks no statistics except for JFR which added some counters directly into the implementation. All statistics are for the users to manage, even if there are helpers for gather these statistics. > > The current implementation is based on what we do for the StringTable and SymbolTable In the other tables, it's called _items_count and it determines the load_factor for triggering concurrent work. We should rename this field items_count to match, and also since it's consistent. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 159: >> >>> 157: static size_t min_log_size() { >>> 158: // ~= log(AvgMonitorsPerThreadEstimate default) >>> 159: return 10; >> >> Uh wait - are we assuming that threads hold 1024 monitors *on average* ? Isn't this a bit excessive? I would have thought maybe 8 monitors/thread. Yes there are workloads that are bonkers. Or maybe the comment/flag name does not say what I think it says. >> >> Or why not use AvgMonitorsPerThreadEstimate directly? > > Maybe that is resonable. I believe I had that at some point but it had to deal with how to handle extreme values of `AvgMonitorsPerThreadEstimate` as well as what to do when `AvgMonitorsPerThreadEstimate` was disabled `=0`. One 4 / 8 KB allocation seems harmless. > > But this was very arbitrary. This will probably be changed when/if the resizing of the table becomes more synchronised with deflation, allowing for shrinking the table. Shrinking the table is NYI. Maybe we should revisit this initial value then. >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 563: >> >>> 561: assert(locking_thread == current || locking_thread->is_obj_deopt_suspend(), "locking_thread may not run concurrently"); >>> 562: if (_no_safepoint) { >>> 563: ::new (&_nsv) NoSafepointVerifier(); >> >> I'm thinking that it might be easier and cleaner to just re-do what the NoSafepointVerifier does? It just calls thread->inc/dec >> _no_safepoint_count(). > > I wanted to avoid having to add `NoSafepointVerifier` implementation details in the synchroniser code. I guess `ContinuationWrapper` already does this. > > Simply creating a `NoSafepointVerifier` when you expect no safepoint is more obvious to me, shows the intent better. This looks strange to me also, but it's be better than changing the no_safepoint_count directly, since NSV handles when the current thread isn't a JavaThread, so you'd have to duplicate that in this VerifyThreadState code too. NoSafepointVerifier::NoSafepointVerifier() : _thread(Thread::current()) { if (_thread->is_Java_thread()) { JavaThread::cast(_thread)->inc_no_safepoint_count(); } } >> src/hotspot/share/runtime/lightweightSynchronizer.hpp line 68: >> >>> 66: static void exit(oop object, JavaThread* current); >>> 67: >>> 68: static ObjectMonitor* inflate_into_object_header(Thread* current, JavaThread* inflating_thread, oop object, const ObjectSynchronizer::InflateCause cause); >> >> My IDE flags this with a warning 'Parameter 'cause' is const-qualified in the function declaration; const-qualification of parameters only has an effect in function definitions' *shrugs* > > Yeah. The only effect is has is that you cannot reassign the variable. It was the style taken from [synchronizer.hpp](https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.hpp) where all `InflateCause` parameters are const. Do you get this for inflate_fast_locked_object also? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688011833 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688162915 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688378429 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688385921 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688397480 From coleenp at openjdk.org Tue Jul 23 19:09:47 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:47 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 06:35:34 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/basicLock.hpp line 44: > >> 42: // a sentinel zero value indicating a recursive stack-lock. >> 43: // * For LM_LIGHTWEIGHT >> 44: // Used as a cache the ObjectMonitor* used when locking. Must either > > The first sentence doesn't read correctly. Suggestion: // Used as a cache of the ObjectMonitor* used when locking. Must either > src/hotspot/share/runtime/deoptimization.cpp line 1641: > >> 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); >> 1640: if (LockingMode == LM_LEGACY) { >> 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); > > In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? Only legacy locking uses the displaced header, I believe, which isn't clear in this code at all. This seems like a fix. We should probably assert that only legacy locking uses this field as a displaced header. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: > >> 60: class ObjectMonitorWorld : public CHeapObj { >> 61: struct Config { >> 62: using Value = ObjectMonitor*; > > Does this alias really help? We don't state the type that many times and it looks odd to end up with a mix of `Value` and `ObjectMonitor*` in the same code. This alias is present in the other CHT implementations, alas as a typedef in StringTable and SymbolTable so this follows the pattern and allows cut/paste of the allocate_node, get_hash, and other functions. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: > >> 100: assert(*value != nullptr, "must be"); >> 101: return (*value)->object_is_cleared(); >> 102: } > > The `is_dead` functions seem oddly placed given they do not relate to the object stored in the wrapper. Why are they here? And what is the difference between `object_is_cleared` and `object_is_dead` (as used by `LookupMonitor`) ? This is a good question. When we look up the Monitor, we don't want to find any that the GC has marked dead, so that's why we call object_is_dead. When we look up with the object to find the Monitor, the object won't be dead (since we're using it to look up). But we don't want to find one that we've cleared because the Monitor was deflated? I don't see where we would clear it though. We clear the WeakHandle in the destructor after the Monitor has been removed from the table. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: > >> 103: }; >> 104: >> 105: class LookupMonitor : public StackObj { > > I'm not understanding why we need this little wrapper class. It's a two way lookup. The plain Lookup class is used to lookup the Monitor given the object. This LookupMonitor class is used to lookup the object given the Monitor. The CHT takes these wrapper classes. Maybe we should rename LookupObject to be more clear? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688013308 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688041218 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688051557 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688375335 PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688168626 From coleenp at openjdk.org Tue Jul 23 19:09:48 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:48 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: <0Dwv0GUezG25Soj6iG3Ti4NCm_RQJdF7psmnDoUAdRU=.c38a44c6-f6e6-4e2a-84ef-45c32d145a13@github.com> Message-ID: On Wed, 17 Jul 2024 06:40:31 GMT, David Holmes wrote: >> src/hotspot/share/runtime/basicLock.hpp line 46: >> >>> 44: // Used as a cache the ObjectMonitor* used when locking. Must either >>> 45: // be nullptr or the ObjectMonitor* used when locking. >>> 46: volatile uintptr_t _metadata; >> >> The displaced header/markword terminology was very well known to people, whereas "metadata" is really abstract - people will always need to go and find out what it actually refers to. Could we not define a union here to support the legacy and lightweight modes more explicitly and keep the existing terminology for the setters/getters for the code that uses it? > > I should have read ahead. I see you do keep the setters/getters. When we remove legacy locking in a couple of releases, we could rename this field cached_monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688015247 From coleenp at openjdk.org Tue Jul 23 19:09:49 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 19:09:49 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: <3m5N_Fh65MVy7vRvO0wq3qFlzxjbCLHhbTBJe8OJorw=.eb61b3bd-5aca-45cd-8e88-389ae86a599b@github.com> On Thu, 18 Jul 2024 11:30:27 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier >> - Remove unused include >> - Update assert message OMCache::set_monitor >> - Fix indentation >> - Remove outdated comment LightweightSynchronizer::exit >> - Remove logStream include >> - Remove strange comment >> - Fix javaThread include > > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: > >> 75: using ConcurrentTable = ConcurrentHashTable; >> 76: >> 77: ConcurrentTable* _table; > > So you have a class ObjectMonitorWorld, which references the ConcurrentTable, which, internally also has its actual table. This is 3 dereferences to get to the actual table, if I counted correctly. I'd try to eliminate the outermost ObjectMonitorWorld class, or at least make it a global flat structure instead of a reference to a heap-allocated object. I think, because this is a structure that is global and would exist throughout the lifetime of the Java program anyway, it might be worth figuring out how to do the actual ConcurrentHashTable flat in the global structure, too. This is a really good suggestion and might help a lot with the performance problems that we see with the table with heavily contended locking. I think we should change this in a follow-on patch (which I'll work on). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688053792 From coleenp at openjdk.org Tue Jul 23 20:24:37 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Jul 2024 20:24:37 GMT Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 13:12:23 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1641: >> >>> 1639: assert(fr.is_deoptimized_frame(), "frame must be scheduled for deoptimization"); >>> 1640: if (LockingMode == LM_LEGACY) { >>> 1641: mon_info->lock()->set_displaced_header(markWord::unused_mark()); >> >> In the existing code how is this restricted to the LM_LEGACY case?? It appears to be unconditional which suggests you are changing the non-UOMT LM_LIGHTWEIGHT logic. ?? > > Only legacy locking uses the displaced header, I believe, which isn't clear in this code at all. This seems like a fix. We should probably assert that only legacy locking uses this field as a displaced header. Update: yes, this code change does assert if you use BasicLock's displaced header for locking modes other than LM_LEGACY. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1688668887 From asmehra at openjdk.org Tue Jul 23 21:50:58 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 23 Jul 2024 21:50:58 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic Message-ID: Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) Testing: test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java ------------- Commit messages: - Update comments in tests to reflect new output format - 8337031: Improvements to CompilationMemoryStatistic Changes: https://git.openjdk.org/jdk/pull/20304/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20304&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337031 Stats: 173 lines in 6 files changed: 77 ins; 21 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/20304.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20304/head:pull/20304 PR: https://git.openjdk.org/jdk/pull/20304 From asmehra at openjdk.org Tue Jul 23 21:50:58 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 23 Jul 2024 21:50:58 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 21:46:50 GMT, Ashutosh Mehra wrote: > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java @tstuefe fyi ------------- PR Comment: https://git.openjdk.org/jdk/pull/20304#issuecomment-2246372292 From sspitsyn at openjdk.org Wed Jul 24 04:40:37 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 04:40:37 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 07:25:44 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > comment tweak Thank you for prompt review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20294#issuecomment-2246852078 From stuefe at openjdk.org Wed Jul 24 06:32:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jul 2024 06:32:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Tue, 23 Jul 2024 17:57:04 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge master > - Fixing formatting > - Inlining buffer and making field private > - Reverting to functional changes in parserTests.cpp > - Error messaging format > - Fixing memory leak > - Fixing pointer style, s/NULL/nullptr, and exception > - Cleaning up parserTests.cpp > - Missing copyright header update > - Adding tests for file dcmd argument > - ... and 5 more: https://git.openjdk.org/jdk/compare/2f2223d7...52ca557d src/hotspot/share/services/diagnosticArgument.cpp line 365: > 363: if (!_value.parse_value(str, len)) { > 364: stringStream error_msg; > 365: error_msg.print("Invalid file path: %s", str); In all likelyhood the only reason Argument::copy_expand... is ever going to fail would be if the expanded string would not fit the buffer in FileArgument. I'd consider a clearer warning here, therefore ("File path invalid or too long: ") src/hotspot/share/services/diagnosticCommand.cpp line 1018: > 1016: // of the default, not the actual default. > 1017: FileArgument file_arg = _filename.value(); > 1018: const char *file = _filename.is_set() ? file_arg.get() : nullptr; Style nit: const char*, not const char * src/hotspot/share/services/diagnosticCommand.cpp line 1197: > 1195: void SystemDumpMapDCmd::execute(DCmdSource source, TRAPS) { > 1196: FileArgument file_arg = _filename.value(); > 1197: const char *name = file_arg.get(); pointer style ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1689204690 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1689206254 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1689208226 From tschatzl at openjdk.org Wed Jul 24 08:38:31 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Jul 2024 08:38:31 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 14:11:20 GMT, Albert Mingkun Yang wrote: > Simple obsoleting a Parallel GC product flag. The flag needs to be added to the obsolete flags table too, not only removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20299#issuecomment-2247230042 From ayang at openjdk.org Wed Jul 24 09:11:13 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 24 Jul 2024 09:11:13 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v2] In-Reply-To: References: Message-ID: > Simple obsoleting a Parallel GC product flag. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20299/files - new: https://git.openjdk.org/jdk/pull/20299/files/59f96d13..10720a6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20299&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20299&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20299/head:pull/20299 PR: https://git.openjdk.org/jdk/pull/20299 From kevinw at openjdk.org Wed Jul 24 10:40:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 24 Jul 2024 10:40:36 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Tue, 23 Jul 2024 17:57:04 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge master > - Fixing formatting > - Inlining buffer and making field private > - Reverting to functional changes in parserTests.cpp > - Error messaging format > - Fixing memory leak > - Fixing pointer style, s/NULL/nullptr, and exception > - Cleaning up parserTests.cpp > - Missing copyright header update > - Adding tests for file dcmd argument > - ... and 5 more: https://git.openjdk.org/jdk/compare/2f2223d7...52ca557d Is the help output working OK? Do these commands' help outputs show the new %p filename? I think it's good that they would. We should expect users of these commands to implicity understand a %p although we can still explain it, e.g. in a separate update in the man page. I just think we should be explicit that the help output is changing. In src/hotspot/share/runtime/java.cpp: if (DumpPerfMapAtExit) { CodeCache::write_perf_map(.... It may need to pass DEFAULT_PERFMAP_FILENAME (and tty). Do you have the change from JDK-8327054 merged into this branch? src/hotspot/share/services/diagnosticArgument.hpp line 65: > 63: class FileArgument { > 64: private: > 65: char _name[1024]; Probably JVM_MAXPATHLEN (which might also be 1024). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2247558224 PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2247560119 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1689545224 From sspitsyn at openjdk.org Wed Jul 24 10:45:35 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 10:45:35 GMT Subject: RFR: 8336254: Virtual thread implementation + test updates [v2] In-Reply-To: References: Message-ID: <9389g2jCKnajfqlGWHttg0RI1HgwODRFKHeuQX3F_ls=.d77bfcc2-b137-4bf5-a325-026229e662e1@github.com> On Fri, 19 Jul 2024 16:59:54 GMT, Alan Bateman wrote: >> Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. >> >> Implementation: >> - Robustness improvements to not throw OOME when unparking a virtual thread. >> - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) >> - VirtualThread changes to reduce contention on timer queues when doing timed-park >> >> Tests: >> - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) >> - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. >> - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java >> - New test for ThreadMXBean.getLockedMonitor with synchronized native methods >> - Reimplement of JVMTI VThreadEvent test to improve reliability >> - Rename some tests to get consistent naming >> - Diagnostic output in several stress tests to help trace progress in the event of a timeout >> >> Testing: tier1-6 > > Alan Bateman 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 eight additional commits since the last revision: > > - Merge > - Fix typo in comment, missing copyright update, test nits > - Merge > - Drop JLA updates for this update > - Merge > - Merge > - Update copyright headers > - Initial commit Looks good. Thank you for porting this to Main line. test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java line 63: > 61: }; > 62: > 63: ThreadFactory factory = VThreadScheduler.virtualThreadFactory(scheduler); Nit: So, there is no name for this thread anymore. Just wanted to note thread names are useful in debugging. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20143#pullrequestreview-2187747262 PR Review Comment: https://git.openjdk.org/jdk/pull/20143#discussion_r1684084924 From stuefe at openjdk.org Wed Jul 24 10:47:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jul 2024 10:47:32 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 21:46:50 GMT, Ashutosh Mehra wrote: > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java I plan to look at this later this week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20304#issuecomment-2247575688 From dholmes at openjdk.org Wed Jul 24 11:55:37 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Jul 2024 11:55:37 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 07:25:44 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > comment tweak Looks okay but one request. Thanks test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 89: > 87: + Thread.currentThread().getName()); > 88: > 89: Thread.yield(); Please add a comment explaining why the yield is present ------------- PR Review: https://git.openjdk.org/jdk/pull/20294#pullrequestreview-2196517572 PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1689636214 From tschatzl at openjdk.org Wed Jul 24 14:38:32 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Jul 2024 14:38:32 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 09:11:13 GMT, Albert Mingkun Yang wrote: >> Simple obsoleting a Parallel GC product flag. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20299#pullrequestreview-2196941028 From szaldana at openjdk.org Wed Jul 24 17:57:59 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 24 Jul 2024 17:57:59 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Wed, 24 Jul 2024 10:35:35 GMT, Kevin Walls wrote: >> Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge master >> - Fixing formatting >> - Inlining buffer and making field private >> - Reverting to functional changes in parserTests.cpp >> - Error messaging format >> - Fixing memory leak >> - Fixing pointer style, s/NULL/nullptr, and exception >> - Cleaning up parserTests.cpp >> - Missing copyright header update >> - Adding tests for file dcmd argument >> - ... and 5 more: https://git.openjdk.org/jdk/compare/2f2223d7...52ca557d > > src/hotspot/share/services/diagnosticArgument.hpp line 65: > >> 63: class FileArgument { >> 64: private: >> 65: char _name[1024]; > > Probably JVM_MAXPATHLEN (which might also be 1024). Hi, I avoided JVM_MAXPATHLEN because of this comment https://github.com/openjdk/jdk/pull/20198#discussion_r1685297940 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1690215958 From szaldana at openjdk.org Wed Jul 24 17:57:58 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 24 Jul 2024 17:57:58 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v10] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: fixing pointer style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/52ca557d..dc1bfe1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Wed Jul 24 18:05:49 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 24 Jul 2024 18:05:49 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v11] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <5KMQ16ZAAx9VI9fpawUyrvQSqll5wzs9lCC1bRL62ow=.34c7def9-ab85-42b7-af4b-a433a5b5cf2c@github.com> > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Updating help text for VM.cds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/dc1bfe1d..34e3f80a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From amenkov at openjdk.org Wed Jul 24 18:36:41 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 24 Jul 2024 18:36:41 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations Message-ID: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. Testing: tier1,tier2,tier3,tier4,hs-tier5-svc ------------- Commit messages: - jcheck - fix Changes: https://git.openjdk.org/jdk/pull/20315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330427 Stats: 192 lines in 7 files changed: 3 ins; 153 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/20315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20315/head:pull/20315 PR: https://git.openjdk.org/jdk/pull/20315 From szaldana at openjdk.org Wed Jul 24 18:40:16 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 24 Jul 2024 18:40:16 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Adding default perfmap filename when invoked outside of diagnostic command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/34e3f80a..d43d90d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=10-11 Stats: 5 lines in 3 files changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From stuefe at openjdk.org Wed Jul 24 18:40:16 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jul 2024 18:40:16 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v11] In-Reply-To: <5KMQ16ZAAx9VI9fpawUyrvQSqll5wzs9lCC1bRL62ow=.34c7def9-ab85-42b7-af4b-a433a5b5cf2c@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <5KMQ16ZAAx9VI9fpawUyrvQSqll5wzs9lCC1bRL62ow=.34c7def9-ab85-42b7-af4b-a433a5b5cf2c@github.com> Message-ID: On Wed, 24 Jul 2024 18:05:49 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Updating help text for VM.cds All good. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2197495698 From szaldana at openjdk.org Wed Jul 24 18:40:16 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 24 Jul 2024 18:40:16 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <8_dPuH2noHgNOFKzsBke96yBSdGoTwhBl0-pyXaoDhA=.e638cdb0-2ea1-42ca-bd8b-88eaf2b719ac@github.com> On Wed, 24 Jul 2024 10:38:01 GMT, Kevin Walls wrote: > In src/hotspot/share/runtime/java.cpp: if (DumpPerfMapAtExit) { CodeCache::write_perf_map(.... > > It may need to pass DEFAULT_PERFMAP_FILENAME (and tty). > > Do you have the change from JDK-8327054 merged into this branch? Good point - I made an update to cover that invocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2248669712 From coleenp at openjdk.org Wed Jul 24 18:56:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Jul 2024 18:56:33 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations In-Reply-To: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Wed, 24 Jul 2024 18:01:15 GMT, Alex Menkov wrote: > Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. > > Testing: tier1,tier2,tier3,tier4,hs-tier5-svc This looks really good. I hadn't expected so much code we had to preserve these. Nice cleanup! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20315#pullrequestreview-2197529968 From sspitsyn at openjdk.org Wed Jul 24 18:59:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 18:59:44 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v3] In-Reply-To: References: Message-ID: <6KqCklLqtCt36poH_1ZNGAbYkyQml_ckUyLGvgtNYks=.455e8093-1412-46af-857a-8700bdc38160@github.com> > The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. > > Thanks to Patricio for reproducing this failure and identifying the root cause: >> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). > The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). > > The fix corrects the assert to account for the `thread->jni_monitor_count()`. > Question: Is the same scenario possible for non-JNI monitors as well? > Also, the fix includes the test tweak described above which makes this failure always reproducible. > > Testing: > - Ran the test `GetOwnedMonitorInfoTest.java` locally > - Mach5 tiers 1-6 are passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: added a comment explaining why extra yield is needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20294/files - new: https://git.openjdk.org/jdk/pull/20294/files/9c10c555..fc336bc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20294/head:pull/20294 PR: https://git.openjdk.org/jdk/pull/20294 From sspitsyn at openjdk.org Wed Jul 24 18:59:45 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 18:59:45 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 11:52:24 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> comment tweak > > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 89: > >> 87: + Thread.currentThread().getName()); >> 88: >> 89: Thread.yield(); > > Please add a comment explaining why the yield is present Thanks, David. Added a comment. Please, let me know if new comment is not good enough. I do not want to explain the whole scenario there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690290073 From dholmes at openjdk.org Wed Jul 24 21:13:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Jul 2024 21:13:31 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v3] In-Reply-To: <6KqCklLqtCt36poH_1ZNGAbYkyQml_ckUyLGvgtNYks=.455e8093-1412-46af-857a-8700bdc38160@github.com> References: <6KqCklLqtCt36poH_1ZNGAbYkyQml_ckUyLGvgtNYks=.455e8093-1412-46af-857a-8700bdc38160@github.com> Message-ID: <8hQbj2NHXH9ZAPteHYG3qxNOLNWGXVK7DemC7fYu-jE=.ef921934-9106-4fd6-9811-275b827791d7@github.com> On Wed, 24 Jul 2024 18:59:44 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > added a comment explaining why extra yield is needed test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 56: > 54: > 55: private static void jniMonitorEnterAndLetObjectDie() { > 56: // The monitor iterator used by GetOwnedMonitorInfo to The original was correct "used to assert" test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 90: > 88: > 89: // Extra unmount helps to reproduce 8334085. > 90: // Two sub-sequential thaws are needed in that sceanrio. s/sceanrio/scenario ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690432483 PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690433117 From dholmes at openjdk.org Wed Jul 24 21:13:33 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Jul 2024 21:13:33 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 18:57:18 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 89: >> >>> 87: + Thread.currentThread().getName()); >>> 88: >>> 89: Thread.yield(); >> >> Please add a comment explaining why the yield is present > > Thanks, David. Added a comment. Please, let me know if new comment is not good enough. I do not want to explain the whole scenario there. The comment is sufficient - thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690435047 From sspitsyn at openjdk.org Wed Jul 24 21:43:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 21:43:44 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v4] In-Reply-To: References: Message-ID: > The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. > > Thanks to Patricio for reproducing this failure and identifying the root cause: >> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). > The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). > > The fix corrects the assert to account for the `thread->jni_monitor_count()`. > Question: Is the same scenario possible for non-JNI monitors as well? > Also, the fix includes the test tweak described above which makes this failure always reproducible. > > Testing: > - Ran the test `GetOwnedMonitorInfoTest.java` locally > - Mach5 tiers 1-6 are passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed typo in new comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20294/files - new: https://git.openjdk.org/jdk/pull/20294/files/fc336bc2..e1dd0169 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20294/head:pull/20294 PR: https://git.openjdk.org/jdk/pull/20294 From sspitsyn at openjdk.org Wed Jul 24 21:43:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 21:43:44 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v3] In-Reply-To: <8hQbj2NHXH9ZAPteHYG3qxNOLNWGXVK7DemC7fYu-jE=.ef921934-9106-4fd6-9811-275b827791d7@github.com> References: <6KqCklLqtCt36poH_1ZNGAbYkyQml_ckUyLGvgtNYks=.455e8093-1412-46af-857a-8700bdc38160@github.com> <8hQbj2NHXH9ZAPteHYG3qxNOLNWGXVK7DemC7fYu-jE=.ef921934-9106-4fd6-9811-275b827791d7@github.com> Message-ID: <0YfOHuIkIEzcltXMqRV_5eHXQHqnhwx5tjdUfYOdfic=.bf65c372-c5a2-44aa-8184-a855af153fbd@github.com> On Wed, 24 Jul 2024 21:08:54 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> added a comment explaining why extra yield is needed > > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 56: > >> 54: >> 55: private static void jniMonitorEnterAndLetObjectDie() { >> 56: // The monitor iterator used by GetOwnedMonitorInfo to > > The original was correct "used to assert" The original was: "used by GetOwnedMonitorInfo used to assert". The word "used" is repeated twice. Changed to: "used by GetOwnedMonitorInfo to assert". Do I miss anything? > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 90: > >> 88: >> 89: // Extra unmount helps to reproduce 8334085. >> 90: // Two sub-sequential thaws are needed in that sceanrio. > > s/sceanrio/scenario Sorry for the typo. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690483888 PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690484412 From sspitsyn at openjdk.org Wed Jul 24 21:43:44 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 21:43:44 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 21:09:55 GMT, David Holmes wrote: >> Thanks, David. Added a comment. Please, let me know if new comment is not good enough. I do not want to explain the whole scenario there. > > The comment is sufficient - thanks Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690484630 From sspitsyn at openjdk.org Wed Jul 24 21:50:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 21:50:01 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v5] In-Reply-To: References: Message-ID: > The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. > > Thanks to Patricio for reproducing this failure and identifying the root cause: >> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). > The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). > > The fix corrects the assert to account for the `thread->jni_monitor_count()`. > Question: Is the same scenario possible for non-JNI monitors as well? > Also, the fix includes the test tweak described above which makes this failure always reproducible. > > Testing: > - Ran the test `GetOwnedMonitorInfoTest.java` locally > - Mach5 tiers 1-6 are passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: restored recently fixed comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20294/files - new: https://git.openjdk.org/jdk/pull/20294/files/e1dd0169..6af3745b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20294&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20294/head:pull/20294 PR: https://git.openjdk.org/jdk/pull/20294 From sspitsyn at openjdk.org Wed Jul 24 21:50:01 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Jul 2024 21:50:01 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v3] In-Reply-To: <0YfOHuIkIEzcltXMqRV_5eHXQHqnhwx5tjdUfYOdfic=.bf65c372-c5a2-44aa-8184-a855af153fbd@github.com> References: <6KqCklLqtCt36poH_1ZNGAbYkyQml_ckUyLGvgtNYks=.455e8093-1412-46af-857a-8700bdc38160@github.com> <8hQbj2NHXH9ZAPteHYG3qxNOLNWGXVK7DemC7fYu-jE=.ef921934-9106-4fd6-9811-275b827791d7@github.com> <0YfOHuIkIEzcltXMqRV_5eHXQHqnhwx5tjdUfYOdfic=.bf65c372-c5a2-44aa-8184-a855af153fbd@github.com> Message-ID: On Wed, 24 Jul 2024 21:38:28 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java line 56: >> >>> 54: >>> 55: private static void jniMonitorEnterAndLetObjectDie() { >>> 56: // The monitor iterator used by GetOwnedMonitorInfo to >> >> The original was correct "used to assert" > > The original was: "used by GetOwnedMonitorInfo used to assert". > The word "used" is repeated twice. > Changed to: "used by GetOwnedMonitorInfo to assert". > Do I miss anything? Okay, thanks. It is a little bit confusing. Restored the original comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20294#discussion_r1690493967 From dholmes at openjdk.org Thu Jul 25 01:20:33 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Jul 2024 01:20:33 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations In-Reply-To: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Wed, 24 Jul 2024 18:01:15 GMT, Alex Menkov wrote: > Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. > > Testing: tier1,tier2,tier3,tier4,hs-tier5-svc Great cleanup - good to see all that complexity go! I think the test can be removed completely - see below. Thanks test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 32: > 30: * @run shell MakeJAR.sh retransformAgent > 31: * @run main/othervm -javaagent:retransformAgent.jar -Xlog:redefine+class=trace RetransformRecordAnnotation > 32: * @run main/othervm -javaagent:retransformAgent.jar -XX:+PreserveAllAnnotations -Xlog:redefine+class=trace RetransformRecordAnnotation This test is described as: * @summary test that records with invisible annotation can be retransformed ``` which suggests to me the test can actually be deleted as it serves no purpose now there are no invisible annotations ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20315#pullrequestreview-2198083244 PR Review Comment: https://git.openjdk.org/jdk/pull/20315#discussion_r1690664957 From dholmes at openjdk.org Thu Jul 25 01:22:41 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Jul 2024 01:22:41 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v5] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 21:50:01 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > restored recently fixed comment Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20294#pullrequestreview-2198085110 From sspitsyn at openjdk.org Thu Jul 25 01:34:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Jul 2024 01:34:32 GMT Subject: RFR: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be [v5] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 21:50:01 GMT, Serguei Spitsyn wrote: >> The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. >> >> Thanks to Patricio for reproducing this failure and identifying the root cause: >>> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). >> The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). >> >> The fix corrects the assert to account for the `thread->jni_monitor_count()`. >> Question: Is the same scenario possible for non-JNI monitors as well? >> Also, the fix includes the test tweak described above which makes this failure always reproducible. >> >> Testing: >> - Ran the test `GetOwnedMonitorInfoTest.java` locally >> - Mach5 tiers 1-6 are passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > restored recently fixed comment Thank you for review, David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20294#issuecomment-2249190841 From sspitsyn at openjdk.org Thu Jul 25 01:37:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Jul 2024 01:37:36 GMT Subject: Integrated: 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 06:58:33 GMT, Serguei Spitsyn wrote: > The test `serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java` is failing with the assert in the `thaw_internal()` function. The assert is not fully correct as it does not account for an unexpected scenario. > > Thanks to Patricio for reproducing this failure and identifying the root cause: >> The problem is that we can unmount a virtual thread, then mount it again, thaw a few frames, execute code that acquires a JNI monitor, and then call thaw again without releasing that monitor. In this test this will happen if the vthread is unmounted in System.out.println("Thread doing JNI call: " ...) because of contention with the main thread doing System.out.println("Main waiting for event."). > The issue can be reproduced by adding Thread.yield() before jniMonitorEnterAndLetObjectDie(). > > The fix corrects the assert to account for the `thread->jni_monitor_count()`. > Question: Is the same scenario possible for non-JNI monitors as well? > Also, the fix includes the test tweak described above which makes this failure always reproducible. > > Testing: > - Ran the test `GetOwnedMonitorInfoTest.java` locally > - Mach5 tiers 1-6 are passed This pull request has now been integrated. Changeset: d3e51daf Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/d3e51daf7331b84b4e78f7f10360848d7c549c1a Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod 8334085: Test crash: assert(thread->held_monitor_count() == 0) failed: Must be Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/20294 From amenkov at openjdk.org Thu Jul 25 01:53:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Jul 2024 01:53:13 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: > Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. > > Testing: tier1,tier2,tier3,tier4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: remove test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20315/files - new: https://git.openjdk.org/jdk/pull/20315/files/03aa9a76..89c83c60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20315&range=00-01 Stats: 186 lines in 1 file changed: 0 ins; 186 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20315/head:pull/20315 PR: https://git.openjdk.org/jdk/pull/20315 From amenkov at openjdk.org Thu Jul 25 01:53:13 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Jul 2024 01:53:13 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Thu, 25 Jul 2024 01:17:14 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> remove test > > test/jdk/java/lang/instrument/RetransformRecordAnnotation.java line 32: > >> 30: * @run shell MakeJAR.sh retransformAgent >> 31: * @run main/othervm -javaagent:retransformAgent.jar -Xlog:redefine+class=trace RetransformRecordAnnotation >> 32: * @run main/othervm -javaagent:retransformAgent.jar -XX:+PreserveAllAnnotations -Xlog:redefine+class=trace RetransformRecordAnnotation > > This test is described as: > > * @summary test that records with invisible annotation can be retransformed > ``` > which suggests to me the test can actually be deleted as it serves no purpose now there are no invisible annotations Agree. Removed the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20315#discussion_r1690681450 From dholmes at openjdk.org Thu Jul 25 01:58:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Jul 2024 01:58:31 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Thu, 25 Jul 2024 01:53:13 GMT, Alex Menkov wrote: >> Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. >> >> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > remove test Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20315#pullrequestreview-2198112296 From kbarrett at openjdk.org Thu Jul 25 04:29:35 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Jul 2024 04:29:35 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v2] In-Reply-To: References: Message-ID: <14S7Ls4AoVfFjxSOeW4N42KZtcvhsJrIe25S9r5FEjg=.03e5738f-bcb6-42d5-831f-a2dc00c01c86@github.com> On Wed, 24 Jul 2024 09:11:13 GMT, Albert Mingkun Yang wrote: >> Simple obsoleting a Parallel GC product flag. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. I assume you will be updating copyrights before integration? ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20299#pullrequestreview-2198278577 From alanb at openjdk.org Thu Jul 25 05:01:41 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 05:01:41 GMT Subject: Integrated: 8336254: Virtual thread implementation + test updates In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robustness and test coverage in the main line. The changes don't include any of the larger changes in the loom repo that are part of future JEPs. > > Implementation: > - Robustness improvements to not throw OOME when unparking a virtual thread. > - Robustness improvements to reduce class loading when a virtual thread parks or parks when pinned (jdk.internal.misc.VirtualThreads is removed, jdk.internal.event.VirtualThreadPinnedEvent is eagerly loaded) > - VirtualThread changes to reduce contention on timer queues when doing timed-park > > Tests: > - New tests for monitor enter/exit/wait/notify (this is a subset of the tests in the loom repo, we can't move many tests because they depend on on the changes to the object monitor implementation) > - New test infrastructure to allow tests use a custom scheduler. This updates many tests to make use of this infrastructure, the "local" ThreadBuidlers is removed. > - More test scenarios added to ThreadAPI and JVMTI GetThreadStateTest.java > - New test for ThreadMXBean.getLockedMonitor with synchronized native methods > - Reimplement of JVMTI VThreadEvent test to improve reliability > - Rename some tests to get consistent naming > - Diagnostic output in several stress tests to help trace progress in the event of a timeout > > Testing: tier1-6 This pull request has now been integrated. Changeset: 6e228ce3 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/6e228ce382d1fad6cba0d0df8a507e6bd32a9a4a Stats: 4114 lines in 42 files changed: 2528 ins; 1150 del; 436 mod 8336254: Virtual thread implementation + test updates Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/20143 From ayang at openjdk.org Thu Jul 25 07:44:45 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Jul 2024 07:44:45 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v3] In-Reply-To: References: Message-ID: > Simple obsoleting a Parallel GC product flag. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20299/files - new: https://git.openjdk.org/jdk/pull/20299/files/10720a6d..def4cff1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20299&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20299&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20299/head:pull/20299 PR: https://git.openjdk.org/jdk/pull/20299 From kevinw at openjdk.org Thu Jul 25 10:57:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Jul 2024 10:57:36 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: <8_dPuH2noHgNOFKzsBke96yBSdGoTwhBl0-pyXaoDhA=.e638cdb0-2ea1-42ca-bd8b-88eaf2b719ac@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> <8_dPuH2noHgNOFKzsBke96yBSdGoTwhBl0-pyXaoDhA=.e638cdb0-2ea1-42ca-bd8b-88eaf2b719ac@github.com> Message-ID: On Wed, 24 Jul 2024 18:36:44 GMT, Sonia Zaldana Calles wrote: > ...made an update to cover that invocation. Thanks for having only one DEFAULT_PERFMAP_FILENAME definition. It could be wrapped with #ifdef LINUX like it was before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250043656 From kevinw at openjdk.org Thu Jul 25 10:57:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Jul 2024 10:57:37 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Wed, 24 Jul 2024 18:40:16 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding default perfmap filename when invoked outside of diagnostic command Do we need to update all the initialisations to set _filename members to type "FILE" ? e.g. HeapDumpDCmd: there is still _filename("filename","Name of the dump file", "STRING",true), ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250044890 From kevinw at openjdk.org Thu Jul 25 11:40:35 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Jul 2024 11:40:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v9] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Wed, 24 Jul 2024 17:54:30 GMT, Sonia Zaldana Calles wrote: >> src/hotspot/share/services/diagnosticArgument.hpp line 65: >> >>> 63: class FileArgument { >>> 64: private: >>> 65: char _name[1024]; >> >> Probably JVM_MAXPATHLEN (which might also be 1024). > > Hi, I avoided JVM_MAXPATHLEN because of this comment https://github.com/openjdk/jdk/pull/20198#discussion_r1685297940 It seems strange to me to NOT use MAXPATHLEN (or JVM_MAXPATHLEN), in this one particular place, based on if somebody rebuilds the JDK on a system where it is defined to be very very long, then there would be some unnecessarily large allocations. There are approx 140 other uses. If JVM_MAXPATHLEN is 4k, we are saying that those other usages reserve the 4k, but this particular path should max out at 1024 bytes? Given common cloud paths and even in our test systems, paths are commonly nearly 400 bytes, so 1024 is not that much spare capacity. I don't want to contradict @tstuefe too much, and it's not make or break for this change, but I would think just go with the standard max path len used everywhere else. If there's a problem with memory bloat, then hardcoding one of the usages isn't really going to help much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1691299887 From kevinw at openjdk.org Thu Jul 25 13:13:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Jul 2024 13:13:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 10:54:43 GMT, Kevin Walls wrote: > Do we need to update all the initialisations to set _filename members to type "FILE" ? I checked, no we don't NEED to change them. We can, it works either way. It does affect the help output. e.g. Arguments: filepath : The file path to the output file (FILE, no default value) ...which would be good as it's a way of telling people these are FILEs therefore %p is interpreted, rather than just a STRING. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250289811 From szaldana at openjdk.org Thu Jul 25 14:48:50 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 25 Jul 2024 14:48:50 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v13] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Wrapping in linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/d43d90d1..33976d70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=11-12 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Thu Jul 25 14:48:50 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 25 Jul 2024 14:48:50 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 13:11:00 GMT, Kevin Walls wrote: > good as it's a way of telling people these are FILEs therefore %p is interpreted, rather than just a STRING. Hi Kevin, I feel this could be more explicit by updating the manpage to explain the %p substitution rather than updating the type to FILE seeing how users are asked to specify a filename rather than an existing file. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250523394 From kevinw at openjdk.org Thu Jul 25 14:53:35 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Jul 2024 14:53:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 14:46:05 GMT, Sonia Zaldana Calles wrote: > > good as it's a way of telling people these are FILEs therefore %p is interpreted, rather than just a STRING. > > Hi Kevin, > > I feel this could be more explicit by updating the manpage to explain the %p substitution rather than updating the type to FILE seeing how users are asked to specify a filename rather than an existing file. What do you think? Hi, I was thinking both 8-) I can do the man page task as that is still closed... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250551321 From jpai at openjdk.org Thu Jul 25 15:20:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 25 Jul 2024 15:20:01 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Message-ID: Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. ------------- Commit messages: - 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Changes: https://git.openjdk.org/jdk/pull/20333/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334167 Stats: 144 lines in 3 files changed: 82 ins; 40 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/20333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20333/head:pull/20333 PR: https://git.openjdk.org/jdk/pull/20333 From szaldana at openjdk.org Thu Jul 25 15:31:05 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 25 Jul 2024 15:31:05 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Adding FILE descriptor for help output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/33976d70..71d3d140 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=12-13 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Thu Jul 25 15:31:05 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Thu, 25 Jul 2024 15:31:05 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v12] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 14:51:22 GMT, Kevin Walls wrote: > > > good as it's a way of telling people these are FILEs therefore %p is interpreted, rather than just a STRING. > > > > > > Hi Kevin, > > I feel this could be more explicit by updating the manpage to explain the %p substitution rather than updating the type to FILE seeing how users are asked to specify a filename rather than an existing file. What do you think? > > Hi, I was thinking both 8-) I can do the man page task as that is still closed... Makes sense. I updated the relevant arguments to `FILE`. > I can do the man page task as that is still closed... That'd be great and thank you for your patience with this review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2250681706 From lmesnik at openjdk.org Thu Jul 25 21:49:36 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 25 Jul 2024 21:49:36 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 15:31:05 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding FILE descriptor for help output Thank you for improving argument handling in jcmd. Please fix small identation problem. Also I would recommend to get approval from svc team reviewer. src/hotspot/share/prims/wbtestmethods/parserTests.cpp line 132: > 130: } else if (strcmp(type, "FILE") == 0) { > 131: DCmdArgument* argument = > 132: new DCmdArgument(name, desc, "FILE", mandatory); Please update identation. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2200510671 PR Review Comment: https://git.openjdk.org/jdk/pull/20198#discussion_r1692165047 From stuefe at openjdk.org Fri Jul 26 06:41:36 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Jul 2024 06:41:36 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 21:46:50 GMT, Ashutosh Mehra wrote: > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java Hi Ashu, generally okay, see remarks. It seems awkward to have a size_t vector with a defined length, and then having to specify the length as input argument. I'd consider either use the good old style of void foo(const size_t array[NUM], ...); (using array with a defined size, but careful since in foo sizeof(array) is still just a pointer) or just write a small wrapper class holding a size_t vector and taking care of the copying. src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 58: > 56: } > 57: > 58: void ArenaStatCounter::init() { Proposal: `reset()` ? src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 115: > 113: for (int tag = 0; tag < Arena::tag_count(); tag++) { > 114: total += _tags_size[tag]; > 115: } Do it with x-macro? src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 118: > 116: if (total != _current) { > 117: log_info(compilation, alloc)("WARNING!!! Total does not match current"); > 118: } Why do we calculate total? Just for this test? I would then put this into an ASSERT section, and make the info log an assert. However, I wonder if this is really needed. The logic updating both _current and _tags_size is pretty straightforward, I don't see how there could be a mismatch. src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 204: > 202: size_t _total; > 203: // usage per arena tag when total peaked > 204: size_t _tags_size_at_peak[Arena::tag_count()]; Can you please make sure Arena::tag_count() evaluates to constexpr? When in doubt, just use the enum value instead. src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 226: > 224: > 225: void set_total(size_t n) { _total = n; } > 226: void set_tags_size_at_peak(size_t* tags_size_at_peak, int nelements) { const size_t* src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 228: > 226: void set_tags_size_at_peak(size_t* tags_size_at_peak, int nelements) { > 227: assert(nelements*sizeof(size_t) <= sizeof(_tags_size_at_peak), "overflow check"); > 228: memcpy(_tags_size_at_peak, tags_size_at_peak, nelements*sizeof(size_t)); style, we do blanks between * (n * x, not n*x) src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 242: > 240: for (int tag = 0; tag < Arena::tag_count(); tag++) { > 241: st->print_cr(" " LEGEND_KEY_FMT ": %s", Arena::tag_name[tag], Arena::tag_desc[tag]); > 242: } use x macro? src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 365: > 363: > 364: void add(const FullMethodName& fmn, CompilerType comptype, > 365: size_t total, size_t* tags_size_at_peak, int nelements, const size_t* src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 471: > 469: _the_table->add(fmn, ct, > 470: arena_stat->peak(), // total > 471: (size_t *)arena_stat->tags_size_at_peak(), Cast should not be needed src/hotspot/share/compiler/compilationMemoryStatistic.hpp line 46: > 44: size_t _peak; > 45: // Current bytes used by arenas per tag > 46: size_t _tags_size[Arena::tag_count()]; Proposal: `_current_by_tag`, referring to _current src/hotspot/share/compiler/compilationMemoryStatistic.hpp line 53: > 51: > 52: // Peak composition: > 53: size_t _tags_size_at_peak[Arena::tag_count()]; `_peak_by_tag` ? src/hotspot/share/memory/arena.cpp line 48: > 46: > 47: #define ARENA_TAG_STRING_(str) #str > 48: #define ARENA_TAG_STRING(name, str, desc) ARENA_TAG_STRING_(str), Can you use STR/XSTR in macros.hpp? src/hotspot/share/memory/arena.hpp line 86: > 84: }; > 85: > 86: #define DO_ARENA_TAG(template) \ Please don't name this template, confuses my IDE. We usually call it DO or XX or something like that src/hotspot/share/memory/arena.hpp line 97: > 95: > 96: #define ARENA_TAG_ENUM_(name) tag_##name > 97: #define ARENA_TAG_ENUM(name, str, desc) ARENA_TAG_ENUM_(name), Here, and in other places: Please try to cut down the number of temp. macros. You can just as well do a enum class Tag { #define XX(name, whatever, whatever2) tag_##name DO_ARENA_TAG(XX) #undef XX num_tags }; here. ------------- PR Review: https://git.openjdk.org/jdk/pull/20304#pullrequestreview-2201007416 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692556908 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692554736 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692556339 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692574321 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692574925 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692577085 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692577477 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692578328 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692579046 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692557726 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692557957 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692559750 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692561100 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1692564129 From sspitsyn at openjdk.org Fri Jul 26 10:42:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Jul 2024 10:42:33 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Thu, 25 Jul 2024 01:53:13 GMT, Alex Menkov wrote: >> Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. >> >> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > remove test Looks good. Really nice simplification. Do I understand it right that all annotations are visible now, or we just do not parse/process invisible ones? If all annotations are visible then can we get rid of the suffix `_visible'? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20315#pullrequestreview-2201523609 From sspitsyn at openjdk.org Fri Jul 26 10:55:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Jul 2024 10:55:31 GMT Subject: RFR: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote: > Fix deadlock with debug agent callbackLock. Details in first comment. > > Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. This looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20282#pullrequestreview-2201548166 From kevinw at openjdk.org Fri Jul 26 11:41:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 26 Jul 2024 11:41:36 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Thu, 25 Jul 2024 15:31:05 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Adding FILE descriptor for help output One more thing that's troubling me. (Apologies it's now and not last week.) I was looking at the _filename.value().get() usage and finding it uncomfortable, compared to the previous simple _filename.value() 8-) Harder to remember and to read and understand. Maybe we can avoid the two accessors, it really is just a char*. These additional argument types look like part of the framework which never found an audience: MemorySizeArgument has one usage in CompilationMemoryStatisticDCmd, NanoTimeArgument looks unused -- so the two-accessor usage is only in once place until now? Adding FileArgument as another of these might be the wrong direction, as these classes are so almost redundant. What if we didn't add FileArgument, and kept using for _filename args/opts: Then in DCmdArgument::parse_value(), recognise a "FILE" argument type and call Arguments::copy_expand_pid there, to set _value. Just seeing if we can cut down some of the complexity here, as Thomas mentioned, it is already very complex for what it is! (There is also the to_string method which seemed like it would be useful here, but it needs a buffer so is more complex than calling two accessors... Another thing that seems to part of the framework that was never much adopted.) ------------- PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2201623426 From jsjolen at openjdk.org Fri Jul 26 12:46:47 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 Jul 2024 12:46:47 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v3] In-Reply-To: References: Message-ID: > Hi, > > Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. > > This opens up for a few new design choices: > > - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. > - Do you have a very large one? Use an `uint64_t`. > > The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. > > One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. > > > > // Old > mid = ((max + min) / 2); > // New > mid = min + ((max - min) / 2); > > Some semi-rigorous thinking: > min \in [0, len) > max \in [0, len) > min <= max > max - min / 2 \in [0, len/2) > Maximizing min and max => len + 0 > Maximizing max, minimizing min => len/2 > Minimizing max, maximizing min => max = min => min > > > // Proof that they're identical when m, h, l \in N > (1) m = l + (h - l) / 2 <=> > 2m = 2l + h - l = h + l > > (2) m = (h + l) / 2 <=> > 2m = h + l > (1) = (2) > QED Johan Sj?len has updated the pull request incrementally with four additional commits since the last revision: - Fix - Apparently this(!) - This? - Use COMMA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20031/files - new: https://git.openjdk.org/jdk/pull/20031/files/b5a87422..937f6eb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20031&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20031&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20031/head:pull/20031 PR: https://git.openjdk.org/jdk/pull/20031 From stuefe at openjdk.org Fri Jul 26 12:46:48 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Jul 2024 12:46:48 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 13:35:36 GMT, Johan Sj?len wrote: >> Hi, >> >> Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. >> >> This opens up for a few new design choices: >> >> - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. >> - Do you have a very large one? Use an `uint64_t`. >> >> The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. >> >> One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. >> >> >> >> // Old >> mid = ((max + min) / 2); >> // New >> mid = min + ((max - min) / 2); >> >> Some semi-rigorous thinking: >> min \in [0, len) >> max \in [0, len) >> min <= max >> max - min / 2 \in [0, len/2) >> Maximizing min and max => len + 0 >> Maximizing max, minimizing min => len/2 >> Minimizing max, maximizing min => max = min => min >> >> >> // Proof that they're identical when m, h, l \in N >> (1) m = l + (h - l) / 2 <=> >> 2m = 2l + h - l = h + l >> >> (2) m = (h + l) / 2 <=> >> 2m = h + l >> (1) = (2) >> QED > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Attempt at fixing GA VMStruct If this is for src/hotspot/share/nmt/arrayWithFreeList.hpp, would it not be a lot simpler to just implement it there, and give it another backing store? In particular because after doing all this work it still won't even support the feature I was hoping for, mainly the ability to put an indexed free list atop of existing memory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20031#issuecomment-2209091083 From jsjolen at openjdk.org Fri Jul 26 12:46:48 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 Jul 2024 12:46:48 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 14:07:57 GMT, Thomas Stuefe wrote: > If this is for src/hotspot/share/nmt/arrayWithFreeList.hpp, would it not be a lot simpler to just implement it there, and give it another backing store? > > In particular because after doing all this work it still won't even support the feature I was hoping for, mainly the ability to put an indexed free list atop of existing memory. I did that first and it sure is simpler, but I'm not sure whether it's a good idea to have to support such a backing storage. See `resizable_array` in here: https://github.com/openjdk/jdk/pull/20002 Still, it does do what you asked for, kind of, see: `GrowableArrayFromArray`. I can adapt AWFL to be able to use either `GAFA` or `GA`. It's also not the only reason to do this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20031#issuecomment-2209118236 From jsjolen at openjdk.org Fri Jul 26 12:46:48 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 Jul 2024 12:46:48 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 13:35:36 GMT, Johan Sj?len wrote: >> Hi, >> >> Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. >> >> This opens up for a few new design choices: >> >> - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. >> - Do you have a very large one? Use an `uint64_t`. >> >> The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. >> >> One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. >> >> >> >> // Old >> mid = ((max + min) / 2); >> // New >> mid = min + ((max - min) / 2); >> >> Some semi-rigorous thinking: >> min \in [0, len) >> max \in [0, len) >> min <= max >> max - min / 2 \in [0, len/2) >> Maximizing min and max => len + 0 >> Maximizing max, minimizing min => len/2 >> Minimizing max, maximizing min => max = min => min >> >> >> // Proof that they're identical when m, h, l \in N >> (1) m = l + (h - l) / 2 <=> >> 2m = 2l + h - l = h + l >> >> (2) m = (h + l) / 2 <=> >> 2m = h + l >> (1) = (2) >> QED > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Attempt at fixing GA VMStruct Compiler issue in linux-x86 seems unrelated to this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20031#issuecomment-2252687347 From duke at openjdk.org Fri Jul 26 12:46:48 2024 From: duke at openjdk.org (Glavo) Date: Fri, 26 Jul 2024 12:46:48 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v3] In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 12:44:31 GMT, Johan Sj?len wrote: >> Hi, >> >> Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. >> >> This opens up for a few new design choices: >> >> - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. >> - Do you have a very large one? Use an `uint64_t`. >> >> The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. >> >> One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. >> >> >> >> // Old >> mid = ((max + min) / 2); >> // New >> mid = min + ((max - min) / 2); >> >> Some semi-rigorous thinking: >> min \in [0, len) >> max \in [0, len) >> min <= max >> max - min / 2 \in [0, len/2) >> Maximizing min and max => len + 0 >> Maximizing max, minimizing min => len/2 >> Minimizing max, maximizing min => max = min => min >> >> >> // Proof that they're identical when m, h, l \in N >> (1) m = l + (h - l) / 2 <=> >> 2m = 2l + h - l = h + l >> >> (2) m = (h + l) / 2 <=> >> 2m = h + l >> (1) = (2) >> QED > > Johan Sj?len has updated the pull request incrementally with four additional commits since the last revision: > > - Fix > - Apparently this(!) > - This? > - Use COMMA src/hotspot/share/classfile/classFileParser.hpp line 46: > 44: class ConstMethod; > 45: class FieldInfo; > 46: template Suggestion: template Is it possible to reduce the changes by providing default parameters? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20031#discussion_r1666447498 From jsjolen at openjdk.org Fri Jul 26 12:46:48 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 Jul 2024 12:46:48 GMT Subject: RFR: 8335701: Make GrowableArray templated by an Index [v3] In-Reply-To: References: Message-ID: <4H6ngLZ5pODKJSClj8mfQx2_B58hNIyA6yW878uF0zk=.fbe42340-3850-4a6a-a529-2b70a4a37b6c@github.com> On Fri, 5 Jul 2024 07:38:12 GMT, Glavo wrote: >> Johan Sj?len has updated the pull request incrementally with four additional commits since the last revision: >> >> - Fix >> - Apparently this(!) >> - This? >> - Use COMMA > > src/hotspot/share/classfile/classFileParser.hpp line 46: > >> 44: class ConstMethod; >> 45: class FieldInfo; >> 46: template > > Suggestion: > > template > > > Is it possible to reduce the changes by providing default parameters? Unfortunately, no. Forward decl.s may not re-define the default template argument, even though they are the same as the definition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20031#discussion_r1666460897 From amenkov at openjdk.org Fri Jul 26 17:59:41 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 26 Jul 2024 17:59:41 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Fri, 26 Jul 2024 10:39:28 GMT, Serguei Spitsyn wrote: > Looks good. Really nice simplification. Do I understand it right that all annotations are visible now, or we just do not parse/process invisible ones? If all annotations are visible then can we get rid of the suffix `_visible'? We skip (do not process) invisible annotations ------------- PR Comment: https://git.openjdk.org/jdk/pull/20315#issuecomment-2253225273 From amenkov at openjdk.org Fri Jul 26 17:59:42 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 26 Jul 2024 17:59:42 GMT Subject: Integrated: 8330427: Obsolete -XX:+PreserveAllAnnotations In-Reply-To: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: On Wed, 24 Jul 2024 18:01:15 GMT, Alex Menkov wrote: > Obsolete PreserveAllAnnotations flag which was deprecated in JDK 23. > > Testing: tier1,tier2,tier3,tier4,hs-tier5-svc This pull request has now been integrated. Changeset: abc4ca5a Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/abc4ca5a8c440f8f3f36a9b35036772c5b5ee7ea Stats: 378 lines in 7 files changed: 3 ins; 339 del; 36 mod 8330427: Obsolete -XX:+PreserveAllAnnotations Reviewed-by: dholmes, sspitsyn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/20315 From asmehra at openjdk.org Fri Jul 26 18:23:33 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Jul 2024 18:23:33 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> On Fri, 26 Jul 2024 06:08:03 GMT, Thomas Stuefe wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 118: > >> 116: if (total != _current) { >> 117: log_info(compilation, alloc)("WARNING!!! Total does not match current"); >> 118: } > > Why do we calculate total? Just for this test? I would then put this into an ASSERT section, and make the info log an assert. > > However, I wonder if this is really needed. The logic updating both _current and _tags_size is pretty straightforward, I don't see how there could be a mismatch. This code should not have been there. I forgot to remove it. There is no use of `total` here. > src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 204: > >> 202: size_t _total; >> 203: // usage per arena tag when total peaked >> 204: size_t _tags_size_at_peak[Arena::tag_count()]; > > Can you please make sure Arena::tag_count() evaluates to constexpr? When in doubt, just use the enum value instead. Arena::tag_count() is declared as a constexpr. I wanted to avoid writing `static_cast(Arena::Tag::tag_count)` every time I need tag_count, so I wrapped it in Arena::tag_count() and declared it with constexpr. Is that not sufficient to make it a constexpr? > src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 242: > >> 240: for (int tag = 0; tag < Arena::tag_count(); tag++) { >> 241: st->print_cr(" " LEGEND_KEY_FMT ": %s", Arena::tag_name[tag], Arena::tag_desc[tag]); >> 242: } > > use x macro? What do you mean by x macro? Do you have an example that shows the use of x macro? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1693443814 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1693443227 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1693445269 From amenkov at openjdk.org Fri Jul 26 21:08:40 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 26 Jul 2024 21:08:40 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other Message-ID: "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). The fix disables the scenarios to remove noise in the CI. ------------- Commit messages: - disable AttachFailed testcases Changes: https://git.openjdk.org/jdk/pull/20362/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20362&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311990 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20362/head:pull/20362 PR: https://git.openjdk.org/jdk/pull/20362 From amenkov at openjdk.org Fri Jul 26 22:50:44 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 26 Jul 2024 22:50:44 GMT Subject: RFR: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote: > Fix deadlock with debug agent callbackLock. Details in first comment. > > Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20282#pullrequestreview-2202833001 From sspitsyn at openjdk.org Sat Jul 27 01:31:48 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 27 Jul 2024 01:31:48 GMT Subject: RFR: 8330427: Obsolete -XX:+PreserveAllAnnotations [v2] In-Reply-To: References: <_2nP9Iruq7HT-LI3HAjSJYs7kubgeqRVQwgtSaLD05Q=.55ddb061-add5-48c1-92ff-53f75b396f54@github.com> Message-ID: <46dVI9rDgSSWdNtPFQF-J-QYMFnG-zKUSe2NlOkxUl0=.c923333c-0450-44a0-b1cb-89f5b776806c@github.com> On Fri, 26 Jul 2024 17:56:27 GMT, Alex Menkov wrote: > We skip (do not process) invisible annotations Okay, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20315#issuecomment-2253694697 From cjplummer at openjdk.org Sat Jul 27 02:00:50 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Jul 2024 02:00:50 GMT Subject: RFR: 8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected Message-ID: The test is setting breakpoints on the wrong line numbers, which causes setting up the breakpoint to fail, but the test also has buggy error checking, so the test doesn't detect the failures and still passes. I fixed the breakpoint line numbers and the error checking. More details in the first comment. Testing tbd: I'll run the tier5 svc testing, which includes this test suite. ------------- Commit messages: - fix breakpoint line numbers. fix test error checking Changes: https://git.openjdk.org/jdk/pull/20366/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20366&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337299 Stats: 60 lines in 2 files changed: 40 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20366/head:pull/20366 PR: https://git.openjdk.org/jdk/pull/20366 From cjplummer at openjdk.org Sat Jul 27 02:00:50 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Jul 2024 02:00:50 GMT Subject: RFR: 8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 01:55:23 GMT, Chris Plummer wrote: > The test is setting breakpoints on the wrong line numbers, which causes setting up the breakpoint to fail, but the test also has buggy error checking, so the test doesn't detect the failures and still passes. I fixed the breakpoint line numbers and the error checking. More details in the first comment. > > Testing tbd: I'll run the tier5 svc testing, which includes this test suite. The test is testing to make sure a jdb deferred breakpoint on an inner class works. The breakpoint line number information for the debuggee is wrong, so the test should be failing, but isn't. The debugger side has: static final String DEBUGGEE_LOCATION1 = DEBUGGEE_CLASS + "$Nested$DeeperNested$DeepestNested:43"; static final String DEBUGGEE_LOCATION2 = DEBUGGEE_CLASS + "$Inner$MoreInner:57"; And the debuggee side has: flag = input; /* <-------- This is line number 43 */ and content += input; /* <-------- This is line number 57 */ However line numbers (even the ones in the comments) are wrong. They probably have been ever since this file was open sourced and the new copyright header was added. As a result, in the jdb out you see failures like: [17:24:22.782] reply[0]: > Unable to set deferred breakpoint nsk.jdb.stop_at.stop_at002.stop_at002a$Nested$DeeperNested$DeepestNested:43 : No code at line 43 in nsk.jdb.stop_at.stop_at002.stop_at002a$Nested$DeeperNested$DeepestNested However, this is not caught by the test. The test only checks for the failed setting of the deferred breakpoint when executing the jdb "stop at" command. The failure does not actually happen until after the test continues, allowing the class to be loaded and for jdb to actually attempt to set the breakpoint. So there are two issues with the test: wrong breakpoint line number information, and failure to determine that a deferred breakpoint failed to be setup when the class was loaded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20366#issuecomment-2253705631 From cjplummer at openjdk.org Sat Jul 27 02:17:48 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Jul 2024 02:17:48 GMT Subject: RFR: 8332488: Add JVMTI DataDumpRequest to the debug agent. Message-ID: JVMTI has a somewhat unique event called DataDumpRequest. One way it is triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the DataDumpRequest event to all agents that have registered for the event callback. The agent is free to do pretty much what it wants during the callback, but the normal usage is to dump anything that might be useful for debugging the agent. In the case of the debug agent, it could dump internal data like the list of known threads and event handlers. After ranked monitor support is complete, it can also dump the state of all jvmti raw monitors that the debug agent uses. I decided to not enable this feature by default, and not make public the option to enable it. This should only be used by developers working on the debug agent, or by users when requested to do so (by debug agent developers) to help debug a debug agent problem. Most of the code executed during the data dump was only available for debug builds, so I've made it available for all builds. Their addition does not affect product builds except for adding a small footprint. TBD is directing the output to a file. This is useful for some of the debugger tests that don't include the debuggee output in the log. This seems to be the case for most com/sun/jdi tests. I decided not to include it for this first pass since it is rather disruptive and detracts from the main changes being made. testing tbd: run all tier1, tier2, and. tie5 svc tests. ------------- Commit messages: - add JVMTI DATA_DUMP_REQUEST support Changes: https://git.openjdk.org/jdk/pull/20367/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332488 Stats: 78 lines in 9 files changed: 39 ins; 27 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20367/head:pull/20367 PR: https://git.openjdk.org/jdk/pull/20367 From stuefe at openjdk.org Sat Jul 27 05:41:36 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Jul 2024 05:41:36 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> References: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> Message-ID: <3FZJyHPjSnJUN-wuslNgoJDIQu6toFSyhagzBPQ_ZV4=.ccd8162b-bb4a-4594-954e-57f43310f219@github.com> On Fri, 26 Jul 2024 18:18:45 GMT, Ashutosh Mehra wrote: >> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 204: >> >>> 202: size_t _total; >>> 203: // usage per arena tag when total peaked >>> 204: size_t _tags_size_at_peak[Arena::tag_count()]; >> >> Can you please make sure Arena::tag_count() evaluates to constexpr? When in doubt, just use the enum value instead. > > Arena::tag_count() is declared as a constexpr. I wanted to avoid writing `static_cast(Arena::Tag::tag_count)` every time I need tag_count, so I wrapped it in Arena::tag_count() and declared it with constexpr. Is that not sufficient to make it a constexpr? Okay then, that is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1693848291 From stuefe at openjdk.org Sat Jul 27 05:46:34 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Jul 2024 05:46:34 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> References: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> Message-ID: On Fri, 26 Jul 2024 18:21:05 GMT, Ashutosh Mehra wrote: >> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 242: >> >>> 240: for (int tag = 0; tag < Arena::tag_count(); tag++) { >>> 241: st->print_cr(" " LEGEND_KEY_FMT ": %s", Arena::tag_name[tag], Arena::tag_desc[tag]); >>> 242: } >> >> use x macro? > > What do you mean by x macro? Do you have an example that shows the use of x macro? You use them already in your patch. E.g. #define XX(name, whatever, desc) st->print_cr(" " LEGEND_KEY_FMT ": " #name #desc DO_ARENA_TAG(XX) #undef XX Admittedly, it is not a lot less code than the for loop. Up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1693851006 From stuefe at openjdk.org Sat Jul 27 06:13:34 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Jul 2024 06:13:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Fri, 26 Jul 2024 11:39:02 GMT, Kevin Walls wrote: > One more thing that's troubling me. (Apologies it's now and not last week.) > > I was looking at the _filename.value().get() usage and finding it uncomfortable, compared to the previous simple _filename.value() 8-) Harder to remember and to read and understand. Maybe we can avoid the two accessors, it really is just a char*. > > These additional argument types look like part of the framework which never found an audience: MemorySizeArgument has one usage in CompilationMemoryStatisticDCmd, NanoTimeArgument looks unused -- so the two-accessor usage is only in once place until now? > > Adding FileArgument as another of these might be the wrong direction, as these classes are so almost redundant. > > What if we didn't add FileArgument, and kept using for _filename args/opts: > > Then in DCmdArgument::parse_value(), recognise a "FILE" argument type and call Arguments::copy_expand_pid there, to set _value. > > Just seeing if we can cut down some of the complexity here, as Thomas mentioned, it is already very complex for what it is! > > (There is also the to_string method which seemed like it would be useful here, but it needs a buffer so is more complex than calling two accessors... Another thing that seems to part of the framework that was never much adopted.) IMHO for a functional addition we should follow the established pattern. Reworking the framework is certainly useful, but I would like it if we could get this done first (I intend to use it in other DCmds). And if we simplify this coding, we should think first about how to do this and what to solve. Things that come to mind: - overuse of template - The argument-type-by-template-division and the runtime "type" string argument (the third argument to DCmdArgument) seem redundant - the fact that we keep command metadata (which should be constant) together with command invocation data (values for arguments that are scoped to a single command invocation) in a single global structure, and then rewrite the latter every time we invoke a command. That is a strange concept and makes cleaning up temporary memory non-trivial - the fact that each new command takes a ton of boilerplate coding (Just see the many many repetitions in diagnosticCommand.cpp) - the fact that we use runtime-polymorphy, which is completely fine, but then all metadata information are "static". So in order to e.g. know how many arguments a command takes, you need to know the command class, since you cannot just call e.g. `num_arguments()` on a `DCmdWithParser*`. I think the whole framework could be done without templates, just using plain old virtual functions instead. This is not code where a vtable lookup really hurts. Just my random thoughts. Maybe there is more, but my point is that if we agree this can be improved, it would be better in a separate RFE, and not mixed into functional RFEs. @lmesnik > Also I would recommend to get approval from svc team reviewer. Who could this be, @plummercj ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2253809524 From cjplummer at openjdk.org Sat Jul 27 07:05:38 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Jul 2024 07:05:38 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 27 Jul 2024 06:11:00 GMT, Thomas Stuefe wrote: > > Also I would recommend to get approval from svc team reviewer. > > Who could this be, @plummercj ? @kevinjwalls is on the svc team and has been involved in this review, and @dholmes-ora, @lmesnik, and @AlanBateman all count as svc reviewers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2253858030 From sspitsyn at openjdk.org Sat Jul 27 10:40:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 27 Jul 2024 10:40:31 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other In-Reply-To: References: Message-ID: <7LFjnyrnBQ6-IGXkT5d2nJpqgYCpdznnTbQ5enL2clQ=.1432f1af-9793-4b3b-9313-2561f67277c6@github.com> On Fri, 26 Jul 2024 21:02:32 GMT, Alex Menkov wrote: > "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). > The fix disables the scenarios to remove noise in the CI. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20362#pullrequestreview-2203157018 From jsjolen at openjdk.org Sun Jul 28 09:50:30 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sun, 28 Jul 2024 09:50:30 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" At the point where this is checked, the commandline string is still not parsed. I do not want any `assert`s regarding the structure of untrusted input. Anyway, PoC of getting "empty" lines such that `is_empty()` is true. I read the code: ```c++ // diagnosticFramework.cpp:387 DCmdIter iter(cmdline, '\n'); // <--- Delimiter right there Hypothesis: Multiple newlines in a message will lead to empty lines. First attempt: I used `jcmd` directly, this failed, as `jcmd` does some clean up on its own. So I had to go with connecting to the PID using Python. My Python 'attacker': import socket import os # My Java PID, connect with JCMD ordinarily to your Java process first to create the PID file, then # replace the numbers with your Java PID socket_path = "/proc/2603121/root/tmp/.java_pid2603121" client = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) print("Connect") print(client.connect(socket_path)) # // The request is: # // 00000 # // where is the protocol version (1), is the command # // name ("load", "datadump", ...), and is an argument connect_payload = "1\x00jcmd\x00\n\n\n\x00\n\n\n\x00\n\n\n\x00" print("Sending payload") print(client.sendall(connect_payload.encode())) print("Sent") # Receive a response from the server response = client.recv(4096) print(f'Received response: {response.decode()}') Later on, in a gdb session for my Java program and where I've connected to the Java process using my Python program: (gdb) p line.is_empty() $6 = true (gdb) p cmdline $7 = 0x7fff68240fc9 "\n\n\n" (gdb) p line $8 = { = {}, _cmd = 0x7fff68240fc9 "\n\n\n", _cmd_len = 0, _args = 0x7fff68240fc9 "\n\n\n", _args_len = 0} (gdb) p bt No symbol "bt" in current context. (gdb) bt #0 DCmd::parse_and_execute (source=DCmd_Source_AttachAPI, out=0x7fffaa62ecc0, cmdline=0x7fff68240fc9 "\n\n\n", delim=32 ' ', __the_thread__=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/share/services/diagnosticFramework.cpp:399 #1 0x00007ffff58f8748 in jcmd (op=0x7fff68240fb0, out=0x7fffaa62ecc0) at /home/johan/jdk/open/src/hotspot/share/services/attachListener.cpp:209 #2 0x00007ffff58f91ae in AttachListenerThread::thread_entry (thread=0x7fff8c001010, __the_thread__=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/share/services/attachListener.cpp:418 #3 0x00007ffff6036294 in JavaThread::thread_main_inner (this=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/share/runtime/javaThread.cpp:757 #4 0x00007ffff6036129 in JavaThread::run (this=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/share/runtime/javaThread.cpp:742 #5 0x00007ffff67c5fb7 in Thread::call_run (this=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/share/runtime/thread.cpp:225 #6 0x00007ffff6549e28 in thread_native_entry (thread=0x7fff8c001010) at /home/johan/jdk/open/src/hotspot/os/linux/os_linux.cpp:858 #7 0x00007ffff7c94ac3 in start_thread (arg=) at ./nptl/pthread_create.c:442 #8 0x00007ffff7d26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) Oh, and also, the output of my Python running: Connect None Sending payload None Sent Received response: -1 java.lang.IllegalArgumentException: Unknown diagnostic command ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2254454215 PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2254454540 From dholmes at openjdk.org Mon Jul 29 00:47:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jul 2024 00:47:32 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 21:02:32 GMT, Alex Menkov wrote: > "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). > The fix disables the scenarios to remove noise in the CI. I'm wondering if this flag should be settable via a property so that you can enable this testing without having to have a modified repo? Otherwise it is not clear when/why someone would go to the effort of changing this and doing this negative testing? ------------- PR Review: https://git.openjdk.org/jdk/pull/20362#pullrequestreview-2203652956 From dholmes at openjdk.org Mon Jul 29 01:19:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jul 2024 01:19:31 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 09:48:21 GMT, Johan Sj?len wrote: >> CmdLine::is_executable() looks wrong, surely an empty line is not executable. >> >> With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. >> >> DCmd tests all good: >> make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" > > Oh, and also, the output of my Python running: > > > Connect > None > Sending payload > None > Sent > Received response: -1 > java.lang.IllegalArgumentException: Unknown diagnostic command @jdksjolen - thank you! IIUC from your report, our own code may never have an empty CmdLine but you can directly inject one using the communication protocol. In that case we the fix is good as-is. A test case would be nice but not if we need to use python. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2254763896 From dholmes at openjdk.org Mon Jul 29 01:36:40 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jul 2024 01:36:40 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: <-AIkwflSHzVq8NCt-kXSBddVapnYdulOmHy0wxnSOzU=.5af3a927-5b9c-453d-8035-899a0b1ee703@github.com> On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Code fix is good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20006#pullrequestreview-2203679120 From kevinw at openjdk.org Mon Jul 29 09:15:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 29 Jul 2024 09:15:37 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 09:48:21 GMT, Johan Sj?len wrote: >> CmdLine::is_executable() looks wrong, surely an empty line is not executable. >> >> With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. >> >> DCmd tests all good: >> make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" > > Oh, and also, the output of my Python running: > > > Connect > None > Sending payload > None > Sent > Received response: -1 > java.lang.IllegalArgumentException: Unknown diagnostic command Thanks Johan @jdksjolen and thanks David! Yes good reminder that there can be multiple lines to process, and we have occasionally seen tools that emulate the attach protocol and send text. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2255411003 From kevinw at openjdk.org Mon Jul 29 09:41:39 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 29 Jul 2024 09:41:39 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Sat, 27 Jul 2024 06:11:00 GMT, Thomas Stuefe wrote: >> One more thing that's troubling me. (Apologies it's now and not last week.) >> >> I was looking at the _filename.value().get() usage and finding it uncomfortable, compared to the previous simple _filename.value() 8-) >> Harder to remember and to read and understand. Maybe we can avoid the two accessors, it really is just a char*. >> >> These additional argument types look like part of the framework which never found an audience: MemorySizeArgument has one usage in CompilationMemoryStatisticDCmd, NanoTimeArgument looks unused -- so the two-accessor usage is only in once place until now? >> >> Adding FileArgument as another of these might be the wrong direction, as these classes are so almost redundant. >> >> What if we didn't add FileArgument, and kept using for _filename args/opts: >> >> Then in DCmdArgument::parse_value(), recognise a "FILE" argument type and call Arguments::copy_expand_pid there, to set _value. >> >> Just seeing if we can cut down some of the complexity here, as Thomas mentioned, it is already very complex for what it is! >> >> >> (There is also the to_string method which seemed like it would be useful here, but it needs a buffer so is more complex than calling two accessors... Another thing that seems to part of the framework that was never much adopted.) > >> One more thing that's troubling me. (Apologies it's now and not last week.) >> >> I was looking at the _filename.value().get() usage and finding it uncomfortable, compared to the previous simple _filename.value() 8-) Harder to remember and to read and understand. Maybe we can avoid the two accessors, it really is just a char*. >> >> These additional argument types look like part of the framework which never found an audience: MemorySizeArgument has one usage in CompilationMemoryStatisticDCmd, NanoTimeArgument looks unused -- so the two-accessor usage is only in once place until now? >> >> Adding FileArgument as another of these might be the wrong direction, as these classes are so almost redundant. >> >> What if we didn't add FileArgument, and kept using for _filename args/opts: >> >> Then in DCmdArgument::parse_value(), recognise a "FILE" argument type and call Arguments::copy_expand_pid there, to set _value. >> >> Just seeing if we can cut down some of the complexity here, as Thomas mentioned, it is already very complex for what it is! >> >> (There is also the to_string method which seemed like it would be useful here, but it needs a buffer so is more complex than calling two accessors... Another thing that seems to part of the framework that was never much adopted.) > > IMHO for a functional addition we should follow the established pattern. Reworking the framework is certainly useful, but I would like it if we could get this done first (I intend to use it in other DCmds). > > And if we simplify this coding, we should think first about how to do this and what to solve. Things that come to mind: > > - overuse of template > - The argument-type-by-template-division and the runtime "type" string argument (the third argument to DCmdArgument) seem redundant > - the fact that we keep command metadata (which should be constant) together with command invocation data (values for arguments that are scoped to a single command invocation) in a single global structure, and then rewrite the latter every time we invoke a command. That is a strange concept and makes cleaning up temporary memory non-trivial > - the fact that each new command takes a ton of boilerplate coding (Just see the many many repetitions in diagnosticCommand.cpp) > - the fact that we use runtime-polymorphy, which is completely fine, but then all metadata information are "static". So in order to e.g. know how many arguments a command takes, you need to know the command class, since you cannot just call e.... Thanks Thomas @tstuefe - We're agreeing that some of this framework is overly complex, and that we aren't going to simplify the framework in this change. But the more we adopt the obscure parts of the framework, the the harder it will be to move away from it, so that's the reason for suggesting not creating the FileArgument class. Use the simpler parts of this machine, with some special cases where necessary, like a char* argument which happens to be used for a FILEname (an input filename which gets %p substitution). The logic I don't follow is: Using this complex mechanism because it exists, when it only has one? actual usage. This seems to contradict the earlier max path len notes where it's suggested not to use a pattern established by about 140 other usages. Apologies Sonia for dragging this out, still really pleased to get this change happening. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2255464478 From jwtang at openjdk.org Mon Jul 29 09:42:09 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 09:42:09 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option Message-ID: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. ------------- Commit messages: - 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option Changes: https://git.openjdk.org/jdk/pull/20373/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337331 Stats: 135 lines in 3 files changed: 135 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20373/head:pull/20373 PR: https://git.openjdk.org/jdk/pull/20373 From jwtang at openjdk.org Mon Jul 29 09:49:11 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 09:49:11 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: > I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20373/files - new: https://git.openjdk.org/jdk/pull/20373/files/d768df02..00ec5887 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20373/head:pull/20373 PR: https://git.openjdk.org/jdk/pull/20373 From dholmes at openjdk.org Mon Jul 29 10:12:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jul 2024 10:12:32 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 09:49:11 GMT, Jiawei Tang wrote: >> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. > > Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option Can we not just preload the problematic class so that it won't happen during the transition? test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved. Please only use a single year here. test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 36: > 34: * @run main/othervm/timeout=100 -Djdk.tracePinnedThreads=full TestPinCaseWithTrace > 35: * @run main/othervm/timeout=100 -javaagent:TestPinCaseWithTrace.jar TestPinCaseWithTrace > 36: * @run main/othervm/timeout=100 -Djdk.tracePinnedThreads=full -javaagent:TestPinCaseWithTrace.jar TestPinCaseWithTrace Unclear why we need the three variants. Also where does the timeout value come from? How long does the test take to run? test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 62: > 60: public static void main(String[] args) throws Exception{ > 61: ExecutorService scheduler = Executors.newFixedThreadPool(1); > 62: Thread.Builder builder = TestPinCaseWithTrace.virtualThreadBuilder(scheduler); Can you not just create a Virtual Thread directly rather than defining a single-threaded executor?? test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/libPinJNI.c line 28: > 26: JNIEXPORT jint JNICALL > 27: Java_TestPinCaseWithTrace_nativeFuncPin(JNIEnv* env, jclass klass, jint x) { > 28: jmethodID nativeBaz = (*env)->GetStaticMethodID(env, klass, "native2Java", "(I)I"); Suggestion: just use `m` rather than `nativeBaz`. ------------- PR Review: https://git.openjdk.org/jdk/pull/20373#pullrequestreview-2204496515 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694947729 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694949670 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694952022 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694954328 From alanb at openjdk.org Mon Jul 29 10:12:34 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 29 Jul 2024 10:12:34 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: <1XAlnt_F0byj_fkmh5Ggy2yPINoYi9wbfceo7HRbhfM=.ac35c579-282b-4f3f-8dac-510fde9a1c8a@github.com> On Mon, 29 Jul 2024 09:49:11 GMT, Jiawei Tang wrote: >> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. > > Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved. I assume you didn't mean to include a date range on a new test. test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 66: > 64: System.out.println("call native: " + nativeFuncPin(1)); > 65: }); > 66: } Does this really need to use a custom scheduler? If not, the running the test with -Djdk.virtualThreadScheduler.maxPoolSize=1 would be simpler. If you really need a custom scheduler, the test can use jdk.test.lib.thread.VThreadScheduler. Also to create a pining scenario it can use jdk.test.lib.thread.VThreadPinner. You'll see examples of both in other tests. test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 70: > 68: static int native2Java(int b) { > 69: try { > 70: Thread.sleep(500); // try yield, will pin, javaagent+tracePinnedThreads will crash here (because of the class `PinnedThreadPrinter`) As noted in the JBS issue, -Djdk.tracePinnedThreads has been very problematic and has been removed in the loom repo as part of the object monitor changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694938805 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694941417 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1694942324 From jsjolen at openjdk.org Mon Jul 29 10:15:31 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 29 Jul 2024 10:15:31 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" FWIW, the Python code maps closely to the standard C/POSIX socket API, it was just a bit quicker to write. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2255536277 From alanb at openjdk.org Mon Jul 29 10:42:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 29 Jul 2024 10:42:30 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 10:09:36 GMT, David Holmes wrote: > Can we not just preload the problematic class so that it won't happen during the transition? It's potentially dozens of classes as it's everything to support the StackWalker API, stream pipelines, and printing code. This diagnostic option is effectively incompatible with the agents that enable the CFLH event. It has other issues and is really a left over from early development. It has been removed in the loom repo, in favour of better JFR events. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20373#issuecomment-2255588034 From jwtang at openjdk.org Mon Jul 29 11:21:31 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 11:21:31 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 10:01:56 GMT, David Holmes wrote: >> Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option > > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 36: > >> 34: * @run main/othervm/timeout=100 -Djdk.tracePinnedThreads=full TestPinCaseWithTrace >> 35: * @run main/othervm/timeout=100 -javaagent:TestPinCaseWithTrace.jar TestPinCaseWithTrace >> 36: * @run main/othervm/timeout=100 -Djdk.tracePinnedThreads=full -javaagent:TestPinCaseWithTrace.jar TestPinCaseWithTrace > > Unclear why we need the three variants. > > Also where does the timeout value come from? How long does the test take to run? I will remove the first two variants. The task will not end because of dead lock in vm. But if the issue is fixed, it can finish in 1s. Considering the differences in platforms and jdk mode(release/debug), I extended the time limit. I'm not sure if I should set this timeout value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695042090 From jwtang at openjdk.org Mon Jul 29 11:30:08 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 11:30:08 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: > I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: changes according to reviewers' advice ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20373/files - new: https://git.openjdk.org/jdk/pull/20373/files/00ec5887..723b1ec6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=01-02 Stats: 33 lines in 2 files changed: 1 ins; 26 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20373/head:pull/20373 PR: https://git.openjdk.org/jdk/pull/20373 From jwtang at openjdk.org Mon Jul 29 11:30:09 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 11:30:09 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: <1XAlnt_F0byj_fkmh5Ggy2yPINoYi9wbfceo7HRbhfM=.ac35c579-282b-4f3f-8dac-510fde9a1c8a@github.com> References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> <1XAlnt_F0byj_fkmh5Ggy2yPINoYi9wbfceo7HRbhfM=.ac35c579-282b-4f3f-8dac-510fde9a1c8a@github.com> Message-ID: On Mon, 29 Jul 2024 09:53:40 GMT, Alan Bateman wrote: >> Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option > > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved. > > I assume you didn't mean to include a date range on a new test. Change it. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 66: > >> 64: System.out.println("call native: " + nativeFuncPin(1)); >> 65: }); >> 66: } > > Does this really need to use a custom scheduler? If not, running the test with -Djdk.virtualThreadScheduler.maxPoolSize=1 would be simpler. If you really need a custom scheduler, the test can use jdk.test.lib.thread.VThreadScheduler. Also to create a pinning scenario it can use jdk.test.lib.thread.VThreadPinner to avoid needing to add JNI code. You'll see examples of both in other tests. Thanks, now I use `-Djdk.virtualThreadScheduler.maxPoolSize=1` instead. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 70: > >> 68: static int native2Java(int b) { >> 69: try { >> 70: Thread.sleep(500); // try yield, will pin, javaagent+tracePinnedThreads will crash here (because of the class `PinnedThreadPrinter`) > > As noted in the JBS issue, -Djdk.tracePinnedThreads has been very problematic and has been removed in the loom repo as part of the object monitor changes. I have read the code in loom and this issue can be resolved by using JFR event instead. But I hope this could be fixed since using javaagent is very common in java application. The root cause is that no new class should be use after the vthread is pinned, since a agent can change the class bytecode and need to use `JvmtiVTMSTransitionDisabler` when transforming class. However, this vthread is in VTMS, it cannot jump out the loop. Using `-Djdk.tracePinnedThreads=full` will use the class `PinnedThreadPrinter` so we end in a deadlock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695049376 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695050299 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695050607 From jwtang at openjdk.org Mon Jul 29 11:30:09 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 11:30:09 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 10:00:23 GMT, David Holmes wrote: >> Jiawei Tang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option > > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved. > > Please only use a single year here. Change it. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 62: > >> 60: public static void main(String[] args) throws Exception{ >> 61: ExecutorService scheduler = Executors.newFixedThreadPool(1); >> 62: Thread.Builder builder = TestPinCaseWithTrace.virtualThreadBuilder(scheduler); > > Can you not just create a Virtual Thread directly rather than defining a single-threaded executor?? Now I use `-Djdk.virtualThreadScheduler.maxPoolSize=1` instead. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/libPinJNI.c line 28: > >> 26: JNIEXPORT jint JNICALL >> 27: Java_TestPinCaseWithTrace_nativeFuncPin(JNIEnv* env, jclass klass, jint x) { >> 28: jmethodID nativeBaz = (*env)->GetStaticMethodID(env, klass, "native2Java", "(I)I"); > > Suggestion: just use `m` rather than `nativeBaz`. Change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695050956 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695052060 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695052254 From jwtang at openjdk.org Mon Jul 29 11:33:31 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Mon, 29 Jul 2024 11:33:31 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 10:40:17 GMT, Alan Bateman wrote: > Can we not just preload the problematic class so that it won't happen during the transition? I think if a new agent are attached into the running progress, the vm may still crash? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20373#issuecomment-2255688446 From jsjolen at openjdk.org Mon Jul 29 12:02:32 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 29 Jul 2024 12:02:32 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20006#pullrequestreview-2204728692 From alanb at openjdk.org Mon Jul 29 12:37:35 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 29 Jul 2024 12:37:35 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v2] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> <1XAlnt_F0byj_fkmh5Ggy2yPINoYi9wbfceo7HRbhfM=.ac35c579-282b-4f3f-8dac-510fde9a1c8a@github.com> Message-ID: On Mon, 29 Jul 2024 11:26:06 GMT, Jiawei Tang wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTraceWithAgent/TestPinCaseWithTrace.java line 70: >> >>> 68: static int native2Java(int b) { >>> 69: try { >>> 70: Thread.sleep(500); // try yield, will pin, javaagent+tracePinnedThreads will crash here (because of the class `PinnedThreadPrinter`) >> >> As noted in the JBS issue, -Djdk.tracePinnedThreads has been very problematic and has been removed in the loom repo as part of the object monitor changes. > > I have read the code in loom and this issue can be resolved by using JFR event instead. But I hope this could be fixed since using javaagent is very common in java application. The root cause is that no new class should be use after the vthread is pinned, since a agent can change the class bytecode and need to use `JvmtiVTMSTransitionDisabler` when transforming class. However, this vthread is in VTMS, it cannot jump out the loop. > > Using `-Djdk.tracePinnedThreads=full` will use the class `PinnedThreadPrinter` so we end in a deadlock. I have no objection to fixing JVMTI, I'm just pointing out that -Djdk.tracePinnedThreads has been very problematic and many other reasons so it will be proposed to be removed when we bring the changes to main line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1695136030 From sgehwolf at openjdk.org Mon Jul 29 14:18:24 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 29 Jul 2024 14:18:24 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v2] In-Reply-To: References: Message-ID: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Severin Gehwolf 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20280/files - new: https://git.openjdk.org/jdk/pull/20280/files/179791a1..179791a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From asmehra at openjdk.org Mon Jul 29 14:49:48 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Jul 2024 14:49:48 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v2] In-Reply-To: References: Message-ID: <5fyuvwoHRU_EUT2tvUsWwzCjd7dazKHMiL0rGWW8jVU=.fed6e33a-7a22-4b4c-950f-d19c18ee0eaf@github.com> > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Address review comments by Thomas S. Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20304/files - new: https://git.openjdk.org/jdk/pull/20304/files/1ffbd696..008ac6b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20304&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20304&range=00-01 Stats: 91 lines in 4 files changed: 31 ins; 30 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/20304.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20304/head:pull/20304 PR: https://git.openjdk.org/jdk/pull/20304 From asmehra at openjdk.org Mon Jul 29 16:05:32 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Jul 2024 16:05:32 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: <9i2-oCVJ5XhCtD5vwX7sgpjg4kbUp-BsKpakhYgE28Q=.5013ceda-dd76-4417-9c81-a8bb3898483d@github.com> On Wed, 24 Jul 2024 10:45:05 GMT, Thomas Stuefe wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > I plan to look at this later this week. @tstuefe I have added a patch to address your review comments. > or just write a small wrapper class holding a size_t vector and taking care of the copying. Using a wrapper class is a good idea. I have added `ArenaTagsCounter` for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20304#issuecomment-2256315773 From asmehra at openjdk.org Mon Jul 29 16:05:33 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Jul 2024 16:05:33 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v2] In-Reply-To: References: <1zW4OT5fJqNOIVmEJzaa75P1pkOtTDCc5o3As0Cbrfg=.37b21e54-fb16-4015-a910-40ead48c94b3@github.com> Message-ID: On Sat, 27 Jul 2024 05:44:14 GMT, Thomas Stuefe wrote: >> What do you mean by x macro? Do you have an example that shows the use of x macro? > > You use them already in your patch. > > E.g. > > > #define XX(name, whatever, desc) st->print_cr(" " LEGEND_KEY_FMT ": " #name #desc > DO_ARENA_TAG(XX) > #undef XX > > > Admittedly, it is not a lot less code than the for loop. Up to you. I will keep the loop if you don't have strong preference for the macro usage here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1695486252 From cjplummer at openjdk.org Mon Jul 29 16:58:43 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Jul 2024 16:58:43 GMT Subject: RFR: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote: > Fix deadlock with debug agent callbackLock. Details in first comment. > > Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. Thank you for the reviews Alex and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20282#issuecomment-2256434639 From cjplummer at openjdk.org Mon Jul 29 16:58:43 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Jul 2024 16:58:43 GMT Subject: Integrated: 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:32:35 GMT, Chris Plummer wrote: > Fix deadlock with debug agent callbackLock. Details in first comment. > > Tested by running all jdi, jdwp, and jdb tests with and without virtual threads about 40 times. The testing was initially done with my hack to force the self suspend (see the first comment in the CR), and then I did final testing without it. I also did final testing with all tier5 svc tests. This pull request has now been integrated. Changeset: c4e6255a Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/c4e6255ac3ec5520c4cb6d0d4ad9013da177ba88 Stats: 44 lines in 5 files changed: 29 ins; 3 del; 12 mod 8332738: Debug agent can deadlock on callbackLock when using StackFrame.PopFrames Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/20282 From cjplummer at openjdk.org Mon Jul 29 17:27:30 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Jul 2024 17:27:30 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 21:02:32 GMT, Alex Menkov wrote: > "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). > The fix disables the scenarios to remove noise in the CI. Was moving the tests to a separate directory and using `exclusiveAccess.dirs=.` considered? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20362#issuecomment-2256495515 From cjplummer at openjdk.org Mon Jul 29 18:06:52 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Jul 2024 18:06:52 GMT Subject: RFR: 8328866: Add raw monitor rank support to the debug agent. [v9] In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: <73vEP-CsplL_ft21wOOpttv6w6o6EPNgI7_7svMXHyY=.3fb979e2-178b-489c-842e-9938581bfed1@github.com> > This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work > > There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process. > > Tested with the following on all supported platforms and with virtual threads: > > com/sun/jdi > vmTestbase/nsk/jdi > vmTestbase/nsk/jdb > vmTestbase/nsk/jdwp > > Still need to run tier2 and tier5. > > Details of the changes follow in the first comment. Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge - Fix a couple of minor typos in comments. - Simplify by getting rid of special logic around leaf monitors. - Flip rank order. Some cleanup and better comments for verifyMonitorRank(). - Fix minor comment typo. - Fix jcheck extra whitespace. - Fix comment typo. - Call verifyMonitorRank() when doing a wait since wait does an exit and enter, so we should do the same rank check that we do during an enter. - Minor comment fix in debugMonitorCreate() - Don't do anything in assertIsCurrentThread() if asserts are disabled - ... and 8 more: https://git.openjdk.org/jdk/compare/c4e6255a...dc978d7a ------------- Changes: https://git.openjdk.org/jdk/pull/19044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19044&range=08 Stats: 590 lines in 11 files changed: 523 ins; 2 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/19044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044 PR: https://git.openjdk.org/jdk/pull/19044 From szaldana at openjdk.org Mon Jul 29 19:01:02 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 29 Jul 2024 19:01:02 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v15] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Reverting FileArgument and using char* instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/71d3d140..2cccc9b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=13-14 Stats: 68 lines in 5 files changed: 12 ins; 41 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Mon Jul 29 19:05:07 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 29 Jul 2024 19:05:07 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v16] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Reverting some lingering changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/2cccc9b4..7f22495a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=14-15 Stats: 6 lines in 2 files changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Mon Jul 29 19:08:17 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 29 Jul 2024 19:08:17 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v17] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: last lingering change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/7f22495a..ceb96eb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From szaldana at openjdk.org Mon Jul 29 19:10:34 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 29 Jul 2024 19:10:34 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v14] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Mon, 29 Jul 2024 09:39:07 GMT, Kevin Walls wrote: >>> One more thing that's troubling me. (Apologies it's now and not last week.) >>> >>> I was looking at the _filename.value().get() usage and finding it uncomfortable, compared to the previous simple _filename.value() 8-) Harder to remember and to read and understand. Maybe we can avoid the two accessors, it really is just a char*. >>> >>> These additional argument types look like part of the framework which never found an audience: MemorySizeArgument has one usage in CompilationMemoryStatisticDCmd, NanoTimeArgument looks unused -- so the two-accessor usage is only in once place until now? >>> >>> Adding FileArgument as another of these might be the wrong direction, as these classes are so almost redundant. >>> >>> What if we didn't add FileArgument, and kept using for _filename args/opts: >>> >>> Then in DCmdArgument::parse_value(), recognise a "FILE" argument type and call Arguments::copy_expand_pid there, to set _value. >>> >>> Just seeing if we can cut down some of the complexity here, as Thomas mentioned, it is already very complex for what it is! >>> >>> (There is also the to_string method which seemed like it would be useful here, but it needs a buffer so is more complex than calling two accessors... Another thing that seems to part of the framework that was never much adopted.) >> >> IMHO for a functional addition we should follow the established pattern. Reworking the framework is certainly useful, but I would like it if we could get this done first (I intend to use it in other DCmds). >> >> And if we simplify this coding, we should think first about how to do this and what to solve. Things that come to mind: >> >> - overuse of template >> - The argument-type-by-template-division and the runtime "type" string argument (the third argument to DCmdArgument) seem redundant >> - the fact that we keep command metadata (which should be constant) together with command invocation data (values for arguments that are scoped to a single command invocation) in a single global structure, and then rewrite the latter every time we invoke a command. That is a strange concept and makes cleaning up temporary memory non-trivial >> - the fact that each new command takes a ton of boilerplate coding (Just see the many many repetitions in diagnosticCommand.cpp) >> - the fact that we use runtime-polymorphy, which is completely fine, but then all metadata information are "static". So in order to e.g. know how many arguments a command takes, you need to know the command c... > > Thanks Thomas @tstuefe - > > We're agreeing that some of this framework is overly complex, and that we aren't going to simplify the framework in this change. > > But the more we adopt the obscure parts of the framework, the the harder it will be to move away from it, so that's the reason for suggesting not creating the FileArgument class. Use the simpler parts of this machine, with some special cases where necessary, like a char* argument which happens to be used for a FILEname (an input filename which gets %p substitution). > > The logic I don't follow is: > Using this complex mechanism because it exists, when it only has one? actual usage. This seems to contradict the earlier max path len notes where it's suggested not to use a pattern established by about 140 other usages. > > Apologies Sonia for dragging this out, still really pleased to get this change happening. Hi @kevinjwalls, I reverted back to `char*` and modified parsing based on the type `FILE`. Really hope this reaches a consensus! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2256698014 From amenkov at openjdk.org Mon Jul 29 19:16:30 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 29 Jul 2024 19:16:30 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other In-Reply-To: References: Message-ID: <1VW2MSzfRKGQ-bF_i4AVDhsNRmcQKPgaZEtyKVUc1Ng=.2390d1b1-9460-4d4e-87af-c51e201ffbf0@github.com> On Mon, 29 Jul 2024 00:45:10 GMT, David Holmes wrote: > I'm wondering if this flag should be settable via a property so that you can enable this testing without having to have a modified repo? Otherwise it is not clear when/why someone would go to the effort of changing this and doing this negative testing? Good suggestion. We have similar flag to disable negative testing in other JDI test, I'll update it too to use the same flag ------------- PR Comment: https://git.openjdk.org/jdk/pull/20362#issuecomment-2256708181 From amenkov at openjdk.org Mon Jul 29 19:20:33 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 29 Jul 2024 19:20:33 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other In-Reply-To: References: Message-ID: <-wsOv3aFmsgA6txyoKHc00zE01YOg-85nk5IRqYE_IY=.ecdde6cb-a84a-40e4-8f52-cefad7a99167@github.com> On Mon, 29 Jul 2024 17:25:03 GMT, Chris Plummer wrote: > Was moving the tests to a separate directory and using `exclusiveAccess.dirs=.` considered? I suppose this test can interfere with many other JDI tests (we have almost 200 in jdk/com/sun/jdi and some in subdirectories) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20362#issuecomment-2256715876 From lmesnik at openjdk.org Mon Jul 29 19:29:35 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 29 Jul 2024 19:29:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v17] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <6gCx1ciA8eMVyM90LMRHr2YcKyTZuPCn8423YIT88aU=.35b32524-4c9d-4974-a67d-2eab1146c258@github.com> On Mon, 29 Jul 2024 19:08:17 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > last lingering change Looks good also. The main goal of my request was to unify arguments paring. /using type FILE for 'char *' seems enough and no need to introduce new filename type for values. Thanks for fixing. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2205814072 From amenkov at openjdk.org Mon Jul 29 21:22:30 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 29 Jul 2024 21:22:30 GMT Subject: RFR: 8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 01:55:23 GMT, Chris Plummer wrote: > The test is setting breakpoints on the wrong line numbers, which causes setting up the breakpoint to fail, but the test also has buggy error checking, so the test doesn't detect the failures and still passes. I fixed the breakpoint line numbers and the error checking. More details in the first comment. > > Testing tbd: I'll run the tier5 svc testing, which includes this test suite. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20366#pullrequestreview-2206116071 From sspitsyn at openjdk.org Mon Jul 29 22:39:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 29 Jul 2024 22:39:36 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 11:30:08 GMT, Jiawei Tang wrote: >> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. > > Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: > > changes according to reviewers' advice src/hotspot/share/prims/jvmtiExport.cpp line 970: > 968: if (_thread->is_in_any_VTMS_transition()) { > 969: return; // no events should be posted if thread is in any VTMS transition > 970: } This is not right place to fix it. This would be better: @@ -1091,8 +1091,8 @@ bool JvmtiExport::post_class_file_load_hook(Symbol* h_name, if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { return false; } - if (JavaThread::current()->is_in_tmp_VTMS_transition()) { - return false; // skip CFLH events in tmp VTMS transition + if (thread->is_in_any_VTMS_transition()) { + return; // no events should be posted if thread is in any VTMS transition } JvmtiClassFileLoadHookPoster poster(h_name, class_loader, Also, there is a check in the constructor `JvmtiClassFileLoadHookPoster()`: if (_thread->is_in_any_VTMS_transition()) { return; // no events should be posted if thread is in any VTMS transition } It is better to replace it with assert. With the right check in the `JvmtiExport::post_class_file_load_hook()` we should never call this constructor and `poster.post()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1696039799 From sspitsyn at openjdk.org Mon Jul 29 23:01:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 29 Jul 2024 23:01:31 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 11:30:08 GMT, Jiawei Tang wrote: >> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. > > Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: > > changes according to reviewers' advice Could you please, do some test renaming/refactoring? We have a number of `.c` JVMTI agents in the testbase. The plan is to convert them to `.cpp` in the future. Can you convert the test use .cpp as well? Also, I'm suggesting to name test directory/files as below: - TestPinCaseWithCFLH/TestPinCaseWithCFLH.java - TestPinCaseWithCFLH/libTestPinCaseWithCFLH.cpp ------------- PR Comment: https://git.openjdk.org/jdk/pull/20373#issuecomment-2257149690 From amenkov at openjdk.org Tue Jul 30 02:04:59 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 30 Jul 2024 02:04:59 GMT Subject: RFR: 8331015: Obsolete -XX:+UseNotificationThread Message-ID: Obsolete UseNotificationThread flag which was deprecated in JDK 23. Testing: tier1..tier5 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/20381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20381&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331015 Stats: 41 lines in 7 files changed: 1 ins; 31 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20381/head:pull/20381 PR: https://git.openjdk.org/jdk/pull/20381 From dholmes at openjdk.org Tue Jul 30 02:48:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Jul 2024 02:48:39 GMT Subject: RFR: 8331015: Obsolete -XX:+UseNotificationThread In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote: > Obsolete UseNotificationThread flag which was deprecated in JDK 23. > > Testing: tier1..tier5 Looks good! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-2206468050 From kbarrett at openjdk.org Tue Jul 30 04:18:02 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Jul 2024 04:18:02 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code Message-ID: Please review this change that removes some uses of literal 0 as a null pointer constant in prims code. Testing: mach5 tier1 ------------- Commit messages: - fix warnings in prims Changes: https://git.openjdk.org/jdk/pull/20385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337418 Stats: 26 lines in 7 files changed: 0 ins; 3 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/20385.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20385/head:pull/20385 PR: https://git.openjdk.org/jdk/pull/20385 From stuefe at openjdk.org Tue Jul 30 04:55:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 30 Jul 2024 04:55:33 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v17] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Mon, 29 Jul 2024 19:08:17 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > last lingering change Okay. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2206633057 From jpai at openjdk.org Tue Jul 30 05:03:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Jul 2024 05:03:37 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. Looking for reviews to backport this one, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20333#issuecomment-2257470071 From stuefe at openjdk.org Tue Jul 30 05:22:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 30 Jul 2024 05:22:32 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v2] In-Reply-To: <5fyuvwoHRU_EUT2tvUsWwzCjd7dazKHMiL0rGWW8jVU=.fed6e33a-7a22-4b4c-950f-d19c18ee0eaf@github.com> References: <5fyuvwoHRU_EUT2tvUsWwzCjd7dazKHMiL0rGWW8jVU=.fed6e33a-7a22-4b4c-950f-d19c18ee0eaf@github.com> Message-ID: On Mon, 29 Jul 2024 14:49:48 GMT, Ashutosh Mehra wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments by Thomas S. > > Signed-off-by: Ashutosh Mehra Minor naming nit, otherwise good. src/hotspot/share/compiler/compilationMemoryStatistic.hpp line 40: > 38: > 39: // Helper class to wrap the array of arena tags for easier processing > 40: class ArenaTagsCounter { Sorry for being a stickler for precise names, but I would like plural for counters here - it is not a single counter, its a series/vector/array of counters. Any of these work for me: ArenaCountersByTag - ArenaCountersByTagVector - ArenaTagCounterVector - ArenaTagCounters ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20304#pullrequestreview-2206660184 PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1696322176 From dholmes at openjdk.org Tue Jul 30 05:32:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Jul 2024 05:32:32 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 Couple of queries on this one. Thanks src/hotspot/share/prims/jni.cpp line 1151: > 1149: \ > 1150: EntryProbe; \ > 1151: ResultType ret{}; \ This looks bogus. ResultType is just a macro variable and could be a primitive type. ?? Does the local need initializing? src/hotspot/share/prims/methodHandles.cpp line 439: > 437: default: > 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid), vmIntrinsics::name_at(iid)); > 439: return 0; Do we no longer need these returns after `fatal` to keep compilers happy? ------------- PR Review: https://git.openjdk.org/jdk/pull/20385#pullrequestreview-2206671959 PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696328696 PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696329565 From cjplummer at openjdk.org Tue Jul 30 05:38:07 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Jul 2024 05:38:07 GMT Subject: RFR: 8328866: Add raw monitor rank support to the debug agent. [v10] In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com> Message-ID: > This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work > > There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process. > > Tested with the following on all supported platforms and with virtual threads: > > com/sun/jdi > vmTestbase/nsk/jdi > vmTestbase/nsk/jdb > vmTestbase/nsk/jdwp > > Still need to run tier2 and tier5. > > Details of the changes follow in the first comment. Chris Plummer has updated the pull request incrementally with two additional commits since the last revision: - Fix some rank orders after merge with 8332738. - tweak to raw monitor dump output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19044/files - new: https://git.openjdk.org/jdk/pull/19044/files/dc978d7a..185233aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19044&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19044&range=08-09 Stats: 16 lines in 2 files changed: 8 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044 PR: https://git.openjdk.org/jdk/pull/19044 From dholmes at openjdk.org Tue Jul 30 06:32:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Jul 2024 06:32:32 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. Backport looks accurate. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20333#pullrequestreview-2206756251 From jwtang at openjdk.org Tue Jul 30 06:46:20 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Tue, 30 Jul 2024 06:46:20 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v4] In-Reply-To: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: > I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: refactor testcase and change the location of fix codes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20373/files - new: https://git.openjdk.org/jdk/pull/20373/files/723b1ec6..1b0de486 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20373&range=02-03 Stats: 230 lines in 5 files changed: 117 ins; 111 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20373/head:pull/20373 PR: https://git.openjdk.org/jdk/pull/20373 From alanb at openjdk.org Tue Jul 30 06:49:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Jul 2024 06:49:31 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 22:58:09 GMT, Serguei Spitsyn wrote: > Can you convert the test to use `.cpp` instead of `.c` as well? or maybe it could use VThreadPinner which allows calling through a native frame for tests like this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20373#issuecomment-2257591543 From kbarrett at openjdk.org Tue Jul 30 06:56:33 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Jul 2024 06:56:33 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 05:27:37 GMT, David Holmes wrote: >> Please review this change that removes some uses of literal 0 as a null >> pointer constant in prims code. >> >> Testing: mach5 tier1 > > src/hotspot/share/prims/jni.cpp line 1151: > >> 1149: \ >> 1150: EntryProbe; \ >> 1151: ResultType ret{}; \ > > This looks bogus. ResultType is just a macro variable and could be a primitive type. ?? Does the local need initializing? This is value-initialization syntax. Value-initialization of a primitive type is zero-initialization. However, I think we don't need the local variable at all. Here and in the other 5(?) similar places, rather than ResultType ret{}; ... ret = jvalue.get_##ResultType(); return ret; I think we could just have ... return jvalue.get_##ResultType(); > src/hotspot/share/prims/methodHandles.cpp line 439: > >> 437: default: >> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid), vmIntrinsics::name_at(iid)); >> 439: return 0; > > Do we no longer need these returns after `fatal` to keep compilers happy? Now that we have, and are using, `[[noreturn]]` on all platforms, we no longer need that dead code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408217 PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408335 From jwtang at openjdk.org Tue Jul 30 06:56:34 2024 From: jwtang at openjdk.org (Jiawei Tang) Date: Tue, 30 Jul 2024 06:56:34 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Mon, 29 Jul 2024 22:34:46 GMT, Serguei Spitsyn wrote: >> Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: >> >> changes according to reviewers' advice > > src/hotspot/share/prims/jvmtiExport.cpp line 970: > >> 968: if (_thread->is_in_any_VTMS_transition()) { >> 969: return; // no events should be posted if thread is in any VTMS transition >> 970: } > > This is not right place to fix it. > > This would be better: > > @@ -1091,8 +1091,8 @@ bool JvmtiExport::post_class_file_load_hook(Symbol* h_name, > if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { > return false; > } > - if (JavaThread::current()->is_in_tmp_VTMS_transition()) { > - return false; // skip CFLH events in tmp VTMS transition > + if (thread->is_in_any_VTMS_transition()) { > + return; // no events should be posted if thread is in any VTMS transition > } > > JvmtiClassFileLoadHookPoster poster(h_name, class_loader, > > > Also, there is a check in the constructor `JvmtiClassFileLoadHookPoster()`: > > if (_thread->is_in_any_VTMS_transition()) { > return; // no events should be posted if thread is in any VTMS transition > } > > It is better to replace it with assert. With the right check in the `JvmtiExport::post_class_file_load_hook()` we should never call this constructor and `poster.post()` when in a VTMS transition. Change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1696407776 From kbarrett at openjdk.org Tue Jul 30 07:18:33 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 Jul 2024 07:18:33 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 06:54:04 GMT, Kim Barrett wrote: >> src/hotspot/share/prims/jni.cpp line 1151: >> >>> 1149: \ >>> 1150: EntryProbe; \ >>> 1151: ResultType ret{}; \ >> >> This looks bogus. ResultType is just a macro variable and could be a primitive type. ?? Does the local need initializing? > > This is value-initialization syntax. Value-initialization of a primitive type is zero-initialization. > > However, I think we don't need the local variable at all. Here and in the other 5(?) similar places, rather than > > ResultType ret{}; > ... > ret = jvalue.get_##ResultType(); > return ret; > > I think we could just have > > ... > return jvalue.get_##ResultType(); Looks like eliminating the variable doesn't work. It gets used in a `DT_RETURN_MARK_FOR` form, which needs the address of the return value. That address is obtained using a reference. Taking a reference to an uninitialized variable is (I think) okay, so long as one doesn't attempt to use the uninitialized value. But then the assignment could be problematic if it's uninitialized and the assignment operator is non-trivial. I expect the compiler will optimize away a trivial zero initialization if it's not needed. So ensuring it is value-initialized seems like the cleanest thing to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696441217 From dholmes at openjdk.org Tue Jul 30 07:57:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Jul 2024 07:57:31 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 Okay - looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20385#pullrequestreview-2206930451 From dholmes at openjdk.org Tue Jul 30 07:57:32 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Jul 2024 07:57:32 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: <2HT3saxNUjevXOwHYDEDT2dIsjjzI6OS8ps6z9oF_nY=.c50ca0b5-5eed-4ce3-b124-fe5c9995fa46@github.com> On Tue, 30 Jul 2024 07:16:21 GMT, Kim Barrett wrote: >> This is value-initialization syntax. Value-initialization of a primitive type is zero-initialization. >> >> However, I think we don't need the local variable at all. Here and in the other 5(?) similar places, rather than >> >> ResultType ret{}; >> ... >> ret = jvalue.get_##ResultType(); >> return ret; >> >> I think we could just have >> >> ... >> return jvalue.get_##ResultType(); > > Looks like eliminating the variable doesn't work. It gets used in a `DT_RETURN_MARK_FOR` form, which > needs the address of the return value. That address is obtained using a reference. Taking a reference > to an uninitialized variable is (I think) okay, so long as one doesn't attempt to use the uninitialized value. > But then the assignment could be problematic if it's uninitialized and the assignment operator is non-trivial. > I expect the compiler will optimize away a trivial zero initialization if it's not needed. So ensuring it is > value-initialized seems like the cleanest thing to do. One day I will remember what this syntax is and does. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696496369 From kevinw at openjdk.org Tue Jul 30 10:14:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Jul 2024 10:14:37 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v17] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <54ySFb85fkY1XfU-2IWvCwIWKijd_F8xS-vWm_wO7KY=.b9713fd9-9b3b-49d2-93fc-57054de1e190@github.com> On Mon, 29 Jul 2024 19:08:17 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > last lingering change Thanks Sonia, and thanks Thomas! I did just see a poblem with DumpPerfMapAtExit that I didn't notice before. When -XX:+DumpPerfMapAtExit causes a call to CodeCache::write_perf_map, there's now no %p substitution so /tmp/perf-%p.map gets created. We all hate duplication but CodeCache::write_perf_map has two very different callers. It could do something like this (feel free to adjust/correct/do something else): src/hotspot/share/code/codeCache.cpp #ifdef LINUX void CodeCache::write_perf_map(const char* filename, outputStream* st) { MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); + if (filename == nullptr) { + st->print_cr("Warning: Not writing perf map as null filename provided."); + return; + } + char fname[JVM_MAXPATHLEN]; + if (strstr(filename, "%p") != nullptr) { + // Unnecessary if filename contains %%p but will be a rare waste of time: + if (!Arguments::copy_expand_pid(filename, strlen(filename), fname, JVM_MAXPATHLEN)) { + st->print_cr("Warning: Not writing perf map as substitution failed."); + return; + } + filename = fname; + } + fileStream fs(filename, "w"); JVM_MAXPATHLEN will have a lot of slack space there as if it contains %p it really should be the default filename, so you could go with a lower value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2257986965 From shade at openjdk.org Tue Jul 30 10:22:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Jul 2024 10:22:32 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 All right, this looks fine. (I am somewhat allergic to `{}` syntax, but it is what it is.) ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20385#pullrequestreview-2207285678 From kevinw at openjdk.org Tue Jul 30 10:47:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Jul 2024 10:47:38 GMT Subject: RFR: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" Thanks for the reviews, integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20006#issuecomment-2258044360 From kevinw at openjdk.org Tue Jul 30 10:47:39 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Jul 2024 10:47:39 GMT Subject: Integrated: 8335610: DiagnosticFramework: CmdLine::is_executable() correction In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 13:58:51 GMT, Kevin Walls wrote: > CmdLine::is_executable() looks wrong, surely an empty line is not executable. > > With this change, in DCmd::parse_and_execute() we will avoid needlessly entering the code block to try and execute the command. > > DCmd tests all good: > make images test TEST="test/hotspot/jtreg/serviceability/dcmd test/jdk/sun/tools/jcmd" This pull request has now been integrated. Changeset: 0325ab8d Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/0325ab8d2353f29ac40ff4b028cbc29bff40c59b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8335610: DiagnosticFramework: CmdLine::is_executable() correction Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/20006 From kevinw at openjdk.org Tue Jul 30 11:07:30 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Jul 2024 11:07:30 GMT Subject: RFR: 8331015: Obsolete -XX:+UseNotificationThread In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote: > Obsolete UseNotificationThread flag which was deprecated in JDK 23. > > Testing: tier1..tier5 Looks good ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-2207376511 From sspitsyn at openjdk.org Tue Jul 30 11:23:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Jul 2024 11:23:32 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v4] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: <-4ohGO-ytRMr_I-4SRpWX6QDeZQCIhVho9mTQadK3MQ=.dff1bb8d-907c-4844-9e1b-801d69984d49@github.com> On Tue, 30 Jul 2024 06:46:20 GMT, Jiawei Tang wrote: >> I add the testcase which can reproduce the crash. I hope that I could get some advise if the codes need changing. > > Jiawei Tang has updated the pull request incrementally with one additional commit since the last revision: > > refactor testcase and change the location of fix codes Changes requested by sspitsyn (Reviewer). src/hotspot/share/prims/jvmtiExport.cpp line 1098: > 1096: if (JavaThread::current()->is_in_any_VTMS_transition()) { > 1097: return false; // no events should be posted if thread is in any VTMS transition > 1098: } Sorry, I was not clear the 3 lines above 1093-1095 had to be replaced with new lines 1096-1098. The check for `is_in_any_VTMS_transition()` includes the checks `is_in_tmp_VTMS_transition()`. ------------- PR Review: https://git.openjdk.org/jdk/pull/20373#pullrequestreview-2207409392 PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1696791636 From sspitsyn at openjdk.org Tue Jul 30 11:27:32 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Jul 2024 11:27:32 GMT Subject: RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v3] In-Reply-To: References: <9hxaRK_d2_alDaHWhl3ilx_M-9TIoi7QiXQ4Lc_LYOo=.3fe67617-7953-4d57-851b-e31959144e0c@github.com> Message-ID: On Tue, 30 Jul 2024 06:46:38 GMT, Alan Bateman wrote: > > Can you convert the test to use .cpp instead of .c as well? > or maybe it could use VThreadPinner which allows calling through a native frame for tests like this. This is a good suggestion, I was also thinking about it. An example can be found in the test: `test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java` ------------- PR Comment: https://git.openjdk.org/jdk/pull/20373#issuecomment-2258119426 From jwaters at openjdk.org Tue Jul 30 11:54:33 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 30 Jul 2024 11:54:33 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 Looks Good! ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/20385#pullrequestreview-2207470079 From jwaters at openjdk.org Tue Jul 30 11:54:34 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 30 Jul 2024 11:54:34 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 06:54:10 GMT, Kim Barrett wrote: >> src/hotspot/share/prims/methodHandles.cpp line 439: >> >>> 437: default: >>> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid), vmIntrinsics::name_at(iid)); >>> 439: return 0; >> >> Do we no longer need these returns after `fatal` to keep compilers happy? > > Now that we have, and are using, `[[noreturn]]` on all platforms, we no longer need that dead code. I'll admit, I do prefer having a return to end all possible control flows in a non void method, but oh well ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696829614 From asmehra at openjdk.org Tue Jul 30 13:35:35 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Jul 2024 13:35:35 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v2] In-Reply-To: References: <5fyuvwoHRU_EUT2tvUsWwzCjd7dazKHMiL0rGWW8jVU=.fed6e33a-7a22-4b4c-950f-d19c18ee0eaf@github.com> Message-ID: On Tue, 30 Jul 2024 05:18:17 GMT, Thomas Stuefe wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments by Thomas S. >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/compiler/compilationMemoryStatistic.hpp line 40: > >> 38: >> 39: // Helper class to wrap the array of arena tags for easier processing >> 40: class ArenaTagsCounter { > > Sorry for being a stickler for precise names, but I would like plural for counters here - it is not a single counter, its a series/vector/array of counters. > Any of these work for me: ArenaCountersByTag - ArenaCountersByTagVector - ArenaTagCounterVector - ArenaTagCounters I am pretty bad in naming things, so I welcome these suggestions. I will go with ArenaCountersByTag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20304#discussion_r1696973723 From szaldana at openjdk.org Tue Jul 30 14:33:10 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 30 Jul 2024 14:33:10 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v18] In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Fixing invocation outside of jcmd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20198/files - new: https://git.openjdk.org/jdk/pull/20198/files/ceb96eb9..564349e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20198&range=16-17 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20198/head:pull/20198 PR: https://git.openjdk.org/jdk/pull/20198 From kevinw at openjdk.org Tue Jul 30 14:52:35 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Jul 2024 14:52:35 GMT Subject: RFR: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID [v18] In-Reply-To: References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: On Tue, 30 Jul 2024 14:33:10 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. >> >> This PR addresses the following diagnostic commands: >> - [x] Compiler.perfmap >> - [x] GC.heap_dump >> - [x] System.dump_map >> - [x] Thread.dump_to_file >> - [x] VM.cds >> >> Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). >> >> I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, >> >> >> filename (Optional) Name of the file to which the flight recording data is >> written when the recording is stopped. If no filename is given, a >> filename is generated from the PID and the current date and is >> placed in the directory where the process was started. The >> filename may also be a directory in which case, the filename is >> generated from the PID and the current date in the specified >> directory. (STRING, no default value) >> >> Note: If a filename is given, '%p' in the filename will be >> replaced by the PID, and '%t' will be replaced by the time in >> 'yyyy_MM_dd_HH_mm_ss' format. >> >> >> Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. >> >> Testing: >> >> - [x] Added test case passes. >> - [x] Modified existing VM.cds tests to also check for `%p` filenames. >> >> Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Fixing invocation outside of jcmd OK great, thanks for that last update, nothing more to say! 8-) I will do the man page update and get it out for review soon. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20198#pullrequestreview-2207924716 PR Comment: https://git.openjdk.org/jdk/pull/20198#issuecomment-2258543294 From asmehra at openjdk.org Tue Jul 30 15:02:51 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Jul 2024 15:02:51 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v3] In-Reply-To: References: Message-ID: <-9CKmLLhUHanmV4kGh3Mzti8od9vxyQAQ_t2hvQVLX4=.c50db040-3a76-42de-ae55-27e4db236fda@github.com> > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Rename ArenaTagsCounter to ArenaCountersByTag Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20304/files - new: https://git.openjdk.org/jdk/pull/20304/files/008ac6b9..70762110 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20304&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20304&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20304.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20304/head:pull/20304 PR: https://git.openjdk.org/jdk/pull/20304 From asmehra at openjdk.org Tue Jul 30 15:02:51 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Jul 2024 15:02:51 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:45:05 GMT, Thomas Stuefe wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > I plan to look at this later this week. @tstuefe renamed ArenaTagsCounter to ArenaCountersByTag ------------- PR Comment: https://git.openjdk.org/jdk/pull/20304#issuecomment-2258563618 From kvn at openjdk.org Tue Jul 30 17:10:33 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Jul 2024 17:10:33 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v3] In-Reply-To: <-9CKmLLhUHanmV4kGh3Mzti8od9vxyQAQ_t2hvQVLX4=.c50db040-3a76-42de-ae55-27e4db236fda@github.com> References: <-9CKmLLhUHanmV4kGh3Mzti8od9vxyQAQ_t2hvQVLX4=.c50db040-3a76-42de-ae55-27e4db236fda@github.com> Message-ID: <_XRsVlxQxbH7kHV8gIwxeK6S2Cy3oT0frrcIzOgQESY=.202dcbf2-3258-417a-933e-eab10e3d7fbc@github.com> On Tue, 30 Jul 2024 15:02:51 GMT, Ashutosh Mehra wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Rename ArenaTagsCounter to ArenaCountersByTag > > Signed-off-by: Ashutosh Mehra Looks reasonable. I submitted our testing to make sure tests passed in our testing. ------------- PR Review: https://git.openjdk.org/jdk/pull/20304#pullrequestreview-2208245618 From duke at openjdk.org Tue Jul 30 17:37:38 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Tue, 30 Jul 2024 17:37:38 GMT Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v6] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 11:07:56 GMT, Sebastian L?vdahl wrote: >> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) > > Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: > > Clarify PID 1 check with comment Waiting for another reviewer to have time to review the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2258866242 From szaldana at openjdk.org Tue Jul 30 18:43:41 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 30 Jul 2024 18:43:41 GMT Subject: Integrated: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID In-Reply-To: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> References: <8kEqL61aS6ZZeLtvifidQhURa2tenl92m5uIAtXAxcE=.31d2d492-7212-4637-99bd-eeff4773a18b@github.com> Message-ID: <7Dk-ApfeC6fpoIAMknLszeWlrg0G-h728jC6iaHn2S4=.e2253687-64ca-48cf-bf2e-9f1a680049c4@github.com> On Tue, 16 Jul 2024 16:25:50 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492) enabling jcmd diagnostic commands that issue an output file to accept the `%p` pattern in the file name and substitute it for the PID. > > This PR addresses the following diagnostic commands: > - [x] Compiler.perfmap > - [x] GC.heap_dump > - [x] System.dump_map > - [x] Thread.dump_to_file > - [x] VM.cds > > Note that some jcmd diagnostic commands already enable this functionality (`JFR.configure, JFR.dump, JFR.start and JFR.stop`). > > I propose opening a separate issue to track updating the man page similarly to how it?s done for the JFR diagnostic commands. For example, > > > filename (Optional) Name of the file to which the flight recording data is > written when the recording is stopped. If no filename is given, a > filename is generated from the PID and the current date and is > placed in the directory where the process was started. The > filename may also be a directory in which case, the filename is > generated from the PID and the current date in the specified > directory. (STRING, no default value) > > Note: If a filename is given, '%p' in the filename will be > replaced by the PID, and '%t' will be replaced by the time in > 'yyyy_MM_dd_HH_mm_ss' format. > > > Unfortunately, per [8276265](https://bugs.openjdk.org/browse/JDK-8276265), sources for the jcmd manpage remain in Oracle internal repos so this PR can?t address that. > > Testing: > > - [x] Added test case passes. > - [x] Modified existing VM.cds tests to also check for `%p` filenames. > > Looking forward to your comments and addressing any diagnostic commands I might have missed (if any). > > Cheers, > Sonia This pull request has now been integrated. Changeset: f5c9e8f1 Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/f5c9e8f1229f3aa00743119a2dee3e15d57048d8 Stats: 173 lines in 11 files changed: 134 ins; 16 del; 23 mod 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Reviewed-by: kevinw, stuefe, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/20198 From amenkov at openjdk.org Tue Jul 30 20:11:03 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 30 Jul 2024 20:11:03 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v2] In-Reply-To: References: Message-ID: > "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). > The fix disables the scenarios to remove noise in the CI. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: add sys.prop to enable negative testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20362/files - new: https://git.openjdk.org/jdk/pull/20362/files/737b0869..0378fc48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20362&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20362&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20362/head:pull/20362 PR: https://git.openjdk.org/jdk/pull/20362 From kvn at openjdk.org Tue Jul 30 21:08:34 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Jul 2024 21:08:34 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic [v3] In-Reply-To: <-9CKmLLhUHanmV4kGh3Mzti8od9vxyQAQ_t2hvQVLX4=.c50db040-3a76-42de-ae55-27e4db236fda@github.com> References: <-9CKmLLhUHanmV4kGh3Mzti8od9vxyQAQ_t2hvQVLX4=.c50db040-3a76-42de-ae55-27e4db236fda@github.com> Message-ID: On Tue, 30 Jul 2024 15:02:51 GMT, Ashutosh Mehra wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Rename ArenaTagsCounter to ArenaCountersByTag > > Signed-off-by: Ashutosh Mehra My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20304#pullrequestreview-2208698602 From sspitsyn at openjdk.org Tue Jul 30 23:17:57 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Jul 2024 23:17:57 GMT Subject: RFR: 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 Message-ID: The test has been fixed to: - add a guard against JVMTI_ERROR_WRONG_PHASE - replace `exit(err)` with `abort()` in the `check_jvmti_error()` The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to prevent JVMTI_ERROR_WRONG_PHASE in the `ClassPrepare` events. Testing: - run the test AllowedFunctions.java locally - TBD: submit a mach5 run for fixed test ------------- Commit messages: - 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 Changes: https://git.openjdk.org/jdk/pull/20397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335836 Stats: 32 lines in 1 file changed: 29 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20397/head:pull/20397 PR: https://git.openjdk.org/jdk/pull/20397 From sspitsyn at openjdk.org Tue Jul 30 23:21:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Jul 2024 23:21:31 GMT Subject: RFR: 8335836: serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java fails with unexpected exit code: 112 In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 23:13:23 GMT, Serguei Spitsyn wrote: > The test has been fixed to: > - add a guard against JVMTI_ERROR_WRONG_PHASE > - replace `exit(err)` with `abort()` in the `check_jvmti_error()` > > The JVMTI `VMDeath` event is enabled and a `RawMonitor` is introduced to prevent JVMTI_ERROR_WRONG_PHASE in the `ClassPrepare` events. > > Testing: > - run the test AllowedFunctions.java locally > - TBD: submit a mach5 run for fixed test Converting the native agent to C++ would simplify the test and allow to use utility functions from the `jvmti_common.hpp`. But I wanted to make the WRONG_PHASE related fix to be clear for reviewers. So, this conversion can be done as a separate step or as a part of a separate effort covered by an enhancement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20397#issuecomment-2259356963 From asmehra at openjdk.org Wed Jul 31 01:38:45 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 31 Jul 2024 01:38:45 GMT Subject: Integrated: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 21:46:50 GMT, Ashutosh Mehra wrote: > Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) > > Testing: > test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java > test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java This pull request has now been integrated. Changeset: e63d0165 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/e63d01654e0b702b3a8c0c4de97a6bb6893fbd1f Stats: 182 lines in 6 files changed: 84 ins; 27 del; 71 mod 8337031: Improvements to CompilationMemoryStatistic Reviewed-by: kvn, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/20304 From asmehra at openjdk.org Wed Jul 31 01:38:44 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 31 Jul 2024 01:38:44 GMT Subject: RFR: 8337031: Improvements to CompilationMemoryStatistic In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 10:45:05 GMT, Thomas Stuefe wrote: >> Some minor improvements to CompilationMemoryStatistic. More details are in [JDK-8337031](https://bugs.openjdk.org/browse/JDK-8337031) >> >> Testing: >> test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java >> test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerMemoryStatisticTest.java > > I plan to look at this later this week. thanks @tstuefe @vnkozlov for reviewing and testing ------------- PR Comment: https://git.openjdk.org/jdk/pull/20304#issuecomment-2259466393 From kbarrett at openjdk.org Wed Jul 31 01:56:31 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Jul 2024 01:56:31 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 11:51:37 GMT, Julian Waters wrote: >> Now that we have, and are using, `[[noreturn]]` on all platforms, we no longer need that dead code. > > I'll admit, I do prefer having a return to end all possible control flows in a non void method, but oh well I would rather it not look like it can return null (or some other manufactured "default") when it actually can't. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1697794269 From kbarrett at openjdk.org Wed Jul 31 02:07:42 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Jul 2024 02:07:42 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: <4vjtLlNagS_WsEeSPaVUHZJsItLG-WvdHxIFTFnEvgk=.1a631179-543a-414e-ba8e-5c72a2f3c976@github.com> On Tue, 30 Jul 2024 10:19:59 GMT, Aleksey Shipilev wrote: > All right, this looks fine. (I am somewhat allergic to `{}` syntax, but it is what it is.) The hoops one had to go through to get guaranteed value-initialization before we had brace initialization are really not pretty. See https://www.boost.org/doc/libs/1_85_0/libs/utility/doc/html/utility/utilities/value_init.html and its associated implementation. It might help if we were to commit to using direct brace initialization whenever appropriate, but that hasn't happened. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20385#issuecomment-2259500102 From jpai at openjdk.org Wed Jul 31 04:46:37 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Jul 2024 04:46:37 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: <9zBPGOp0JLzqWULSfc34EDfL-16JU4iIDOUdoNNUOv8=.32b4bdf2-431a-4c4b-8ee7-48da7e76f7d0@github.com> On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. Thank you David for the review. Given that this is the serviceability area, can I get a second review please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20333#issuecomment-2259632800 From sspitsyn at openjdk.org Wed Jul 31 07:54:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 07:54:31 GMT Subject: RFR: 8337299: vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java failure goes undetected In-Reply-To: References: Message-ID: <5NWnmoedvGFP-Bk0reG0KTNSzXT4LEaztN65kEPl4bM=.c3e39981-7b76-43a0-bf19-6e41b8828f24@github.com> On Sat, 27 Jul 2024 01:55:23 GMT, Chris Plummer wrote: > The test is setting breakpoints on the wrong line numbers, which causes setting up the breakpoint to fail, but the test also has buggy error checking, so the test doesn't detect the failures and still passes. I fixed the breakpoint line numbers and the error checking. More details in the first comment. > > Testing tbd: I'll run the tier5 svc testing, which includes this test suite. This looks good. I've posted one question. test/hotspot/jtreg/vmTestbase/nsk/jdb/stop_at/stop_at002/stop_at002.java line 147: > 145: } > 146: > 147: found = grep.findFirst("Breakpoint hit: \"thread=main\", "); Q: Is it possible to check for the exact breakpoint location here? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20366#pullrequestreview-2209432354 PR Review Comment: https://git.openjdk.org/jdk/pull/20366#discussion_r1698063176 From sspitsyn at openjdk.org Wed Jul 31 08:06:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 08:06:33 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 20:11:03 GMT, Alex Menkov wrote: >> "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). >> The fix disables the scenarios to remove noise in the CI. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > add sys.prop to enable negative testing The update looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20362#pullrequestreview-2209458874 From sspitsyn at openjdk.org Wed Jul 31 08:21:34 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 08:21:34 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 Looks good. Thank you for fixing this! The `ResultType ret{};` syntax is a little bit unusual but I'm okay with that. :) ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20385#pullrequestreview-2209490825 From sspitsyn at openjdk.org Wed Jul 31 08:27:31 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 08:27:31 GMT Subject: RFR: 8331015: Obsolete -XX:+UseNotificationThread In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote: > Obsolete UseNotificationThread flag which was deprecated in JDK 23. > > Testing: tier1..tier5 Marked as reviewed by sspitsyn (Reviewer). Looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-2209502256 PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-2209502965 From kevinw at openjdk.org Wed Jul 31 08:37:57 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 31 Jul 2024 08:37:57 GMT Subject: RFR: 8337276: jcmd man page update for PID in output filenames In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls wrote: > Man page update for jcmd. > > Add updates for the filename options/arguments affected by: > 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID > > Also: > In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section. > > In Description: > Each diagnostic command has its own set of options and arguments . > > Added "options and" because arguments and options are different and this can still be confusing. Mentioning them as being different may help. > > Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing. Attached plain text of updated man page: [jcmd.manpage.txt](https://github.com/user-attachments/files/16438536/jcmd.manpage.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20401#issuecomment-2259961165 From kevinw at openjdk.org Wed Jul 31 08:37:57 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 31 Jul 2024 08:37:57 GMT Subject: RFR: 8337276: jcmd man page update for PID in output filenames Message-ID: Man page update for jcmd. Add updates for the filename options/arguments affected by: 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID Also: In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section. In Description: Each diagnostic command has its own set of options and arguments . Added "options and" because arguments and options are different and this can still be confusing. Mentioning them as being different may help. Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing. ------------- Commit messages: - 8337276: jcmd man page update for PID in output filenames Changes: https://git.openjdk.org/jdk/pull/20401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337276 Stats: 36 lines in 1 file changed: 11 ins; 11 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/20401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20401/head:pull/20401 PR: https://git.openjdk.org/jdk/pull/20401 From sspitsyn at openjdk.org Wed Jul 31 10:14:36 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 10:14:36 GMT Subject: RFR: 8332488: Add JVMTI DataDumpRequest to the debug agent. In-Reply-To: References: Message-ID: On Sat, 27 Jul 2024 02:12:33 GMT, Chris Plummer wrote: > JVMTI has a somewhat unique event called DataDumpRequest. One way it is triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the DataDumpRequest event to all agents that have registered for the event callback. The agent is free to do pretty much what it wants during the callback, but the normal usage is to dump anything that might be useful for debugging the agent. In the case of the debug agent, it could dump internal data like the list of known threads and event handlers. After ranked monitor support is complete, it can also dump the state of all jvmti raw monitors that the debug agent uses. > > I decided to not enable this feature by default, and not make public the option to enable it. This should only be used by developers working on the debug agent, or by users when requested to do so (by debug agent developers) to help debug a debug agent problem. > > Most of the code executed during the data dump was only available for debug builds, so I've made it available for all builds. Their addition does not affect product builds except for adding a small footprint. > > TBD is directing the output to a file. This is useful for some of the debugger tests that don't include the debuggee output in the log. This seems to be the case for most com/sun/jdi tests. I decided not to include it for this first pass since it is rather disruptive and detracts from the main changes being made. > > testing tbd: run all tier1, tier2, and. tie5 svc tests. First, it is a good idea to implement/enable this. It looks good in general. Need another pass to understand the implications better. Did you consider to add a test for this? ------------- PR Review: https://git.openjdk.org/jdk/pull/20367#pullrequestreview-2209752865 From sspitsyn at openjdk.org Wed Jul 31 10:26:34 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Jul 2024 10:26:34 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. The backport looks correct. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20333#pullrequestreview-2209775883 From jpai at openjdk.org Wed Jul 31 10:43:42 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Jul 2024 10:43:42 GMT Subject: [jdk23] RFR: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. Thank you Serguei. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20333#issuecomment-2260215530 From jpai at openjdk.org Wed Jul 31 10:43:43 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Jul 2024 10:43:43 GMT Subject: [jdk23] Integrated: 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 15:13:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only backport of the fix that we did in master branch a few weeks back? > > This isn't a clean backport, there were trivial merge issues in the `NativeMethodPrefixApp` test class, which I have resolved manually. The merged content matches with what we have in master branch. The original fix was done in https://github.com/openjdk/jdk/pull/20154 and we have seen this test fail since it was integrated. > > Backporting this to jdk23 branch will provide test stability in that branch where currently this test occasionally times out. This pull request has now been integrated. Changeset: 946c6cc6 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/946c6cc6c77a16919e13a619a4372ac989c35e26 Stats: 144 lines in 3 files changed: 82 ins; 40 del; 22 mod 8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out Reviewed-by: dholmes, sspitsyn Backport-of: 3babffd4002be62f9f75a1a773c9561804612fad ------------- PR: https://git.openjdk.org/jdk/pull/20333 From ayang at openjdk.org Wed Jul 31 11:32:00 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 31 Jul 2024 11:32:00 GMT Subject: RFR: 8337546: Remove unused GCCause::_adaptive_size_policy Message-ID: Trivial removing an unused gc-cause; it was previously used by Parallel only. ------------- Commit messages: - remove-gc-cause Changes: https://git.openjdk.org/jdk/pull/20403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337546 Stats: 13 lines in 4 files changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20403/head:pull/20403 PR: https://git.openjdk.org/jdk/pull/20403 From kevinw at openjdk.org Wed Jul 31 11:52:59 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 31 Jul 2024 11:52:59 GMT Subject: RFR: 8337473: Remove sun/management/jdp tests from ProblemList on Linux-aarch64, MacOSX Message-ID: Problemlist update only, should be trivial: Remove problemlist entries for sun/management/jdp tests on MacOS and Linux. 8241865 was a failure last seen July 2022. Was related to 8241530 com/sun/jdi tests fail due to network issues on OSX 10.15 Originally logged for macOS failures but Linux failures also seen. The tests all pass 20 times in a row on the affected platforms. They remain problemlisted for JDK-8308807 on AIX. ------------- Commit messages: - 8337473: Remove sun/management/jdp tests from ProblemList on Linux-aarch64, MacOSX Changes: https://git.openjdk.org/jdk/pull/20402/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20402&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337473 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20402/head:pull/20402 PR: https://git.openjdk.org/jdk/pull/20402 From dholmes at openjdk.org Wed Jul 31 12:11:33 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Jul 2024 12:11:33 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v2] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 20:11:03 GMT, Alex Menkov wrote: >> "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). >> The fix disables the scenarios to remove noise in the CI. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > add sys.prop to enable negative testing test/jdk/com/sun/jdi/JdwpListenTest.java line 54: > 52: // It's off by default as it causes test time increase and test interference (see JDK-8231915). > 53: private static boolean allowNegativeTesting = > 54: "true".equalsIgnoreCase(System.getProperty("JDI_ALLOW_NEGATIVE_TESTING")); That seems a strange name for a system property - it would normally be something like jdk.jdi.allowNegativeTesting. Is this style of naming being used elsewhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20362#discussion_r1698399300 From coleenp at openjdk.org Wed Jul 31 12:26:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Jul 2024 12:26:33 GMT Subject: RFR: 8331015: Obsolete -XX:+UseNotificationThread In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote: > Obsolete UseNotificationThread flag which was deprecated in JDK 23. > > Testing: tier1..tier5 Thank you for doing this. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20381#pullrequestreview-2210020383 From tschatzl at openjdk.org Wed Jul 31 13:12:33 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 31 Jul 2024 13:12:33 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v3] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 07:44:45 GMT, Albert Mingkun Yang wrote: >> Simple obsoleting a Parallel GC product flag. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > copyright Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20299#pullrequestreview-2210127266 From kbarrett at openjdk.org Wed Jul 31 13:14:36 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Jul 2024 13:14:36 GMT Subject: RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 07:54:43 GMT, David Holmes wrote: >> Please review this change that removes some uses of literal 0 as a null >> pointer constant in prims code. >> >> Testing: mach5 tier1 > > Okay - looks good. Thanks. Thanks for reviews @dholmes-ora , @shipilev , @TheShermanTanker , and @sspitsyn . ------------- PR Comment: https://git.openjdk.org/jdk/pull/20385#issuecomment-2260494132 From kbarrett at openjdk.org Wed Jul 31 13:18:46 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Jul 2024 13:18:46 GMT Subject: Integrated: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote: > Please review this change that removes some uses of literal 0 as a null > pointer constant in prims code. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 07dd7250 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/07dd725025a54035436a76ac4c0a8bb2b12e264a Stats: 26 lines in 7 files changed: 0 ins; 3 del; 23 mod 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code Reviewed-by: dholmes, shade, jwaters, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/20385 From tschatzl at openjdk.org Wed Jul 31 13:29:32 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 31 Jul 2024 13:29:32 GMT Subject: RFR: 8337546: Remove unused GCCause::_adaptive_size_policy In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 11:25:50 GMT, Albert Mingkun Yang wrote: > Trivial removing an unused gc-cause; it was previously used by Parallel only. Good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20403#pullrequestreview-2210168192 From kbarrett at openjdk.org Wed Jul 31 13:29:33 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 31 Jul 2024 13:29:33 GMT Subject: RFR: 8337546: Remove unused GCCause::_adaptive_size_policy In-Reply-To: References: Message-ID: <5oVJOB_OmdBtra0NImrqPvDCfneIQJnN7dW6YyOx3zc=.608a67f3-ad10-4946-9372-da4355862e45@github.com> On Wed, 31 Jul 2024 11:25:50 GMT, Albert Mingkun Yang wrote: > Trivial removing an unused gc-cause; it was previously used by Parallel only. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20403#pullrequestreview-2210171121 From ayang at openjdk.org Wed Jul 31 16:26:36 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 31 Jul 2024 16:26:36 GMT Subject: RFR: 8337027: Parallel: Obsolete BaseFootPrintEstimate [v3] In-Reply-To: References: Message-ID: On Thu, 25 Jul 2024 07:44:45 GMT, Albert Mingkun Yang wrote: >> Simple obsoleting a Parallel GC product flag. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > copyright Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20299#issuecomment-2260902728 From ayang at openjdk.org Wed Jul 31 16:26:36 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 31 Jul 2024 16:26:36 GMT Subject: Integrated: 8337027: Parallel: Obsolete BaseFootPrintEstimate In-Reply-To: References: Message-ID: On Tue, 23 Jul 2024 14:11:20 GMT, Albert Mingkun Yang wrote: > Simple obsoleting a Parallel GC product flag. This pull request has now been integrated. Changeset: e4c7850c Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/e4c7850c177899a5da6f5050cb0647a6e1a75d31 Stats: 34 lines in 7 files changed: 2 ins; 25 del; 7 mod 8337027: Parallel: Obsolete BaseFootPrintEstimate Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/20299 From cjplummer at openjdk.org Wed Jul 31 16:53:38 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 31 Jul 2024 16:53:38 GMT Subject: RFR: 8332488: Add JVMTI DataDumpRequest to the debug agent. In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 10:12:16 GMT, Serguei Spitsyn wrote: > Did you consider to add a test for this? Good idea. I'll add one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20367#issuecomment-2260951141 From amenkov at openjdk.org Wed Jul 31 19:50:01 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Jul 2024 19:50:01 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v3] In-Reply-To: References: Message-ID: > "Attach fails" scenarios (debuggee starts listening and debugger is expected to fail trying to attach) sometimes interfere with other JDI tests (so JdwpNetProps.java test or other JDI test or both fail). > The fix disables the scenarios to remove noise in the CI. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: rename sys.property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20362/files - new: https://git.openjdk.org/jdk/pull/20362/files/0378fc48..87d8128a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20362&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20362&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20362.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20362/head:pull/20362 PR: https://git.openjdk.org/jdk/pull/20362 From amenkov at openjdk.org Wed Jul 31 19:58:31 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Jul 2024 19:58:31 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 12:08:33 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> add sys.prop to enable negative testing > > test/jdk/com/sun/jdi/JdwpListenTest.java line 54: > >> 52: // It's off by default as it causes test time increase and test interference (see JDK-8231915). >> 53: private static boolean allowNegativeTesting = >> 54: "true".equalsIgnoreCase(System.getProperty("JDI_ALLOW_NEGATIVE_TESTING")); > > That seems a strange name for a system property - it would normally be something like jdk.jdi.allowNegativeTesting. Is this style of naming being used elsewhere? Renamed as suggested. IIRC we had `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual` some time ago. Other tests use "standard" naming ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20362#discussion_r1699033342 From amenkov at openjdk.org Wed Jul 31 20:05:37 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Jul 2024 20:05:37 GMT Subject: Integrated: 8331015: Obsolete -XX:+UseNotificationThread In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 01:57:33 GMT, Alex Menkov wrote: > Obsolete UseNotificationThread flag which was deprecated in JDK 23. > > Testing: tier1..tier5 This pull request has now been integrated. Changeset: 8af2ef35 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/8af2ef35b6f9399b6d25ff7a4a72ad283df63f03 Stats: 41 lines in 7 files changed: 1 ins; 31 del; 9 mod 8331015: Obsolete -XX:+UseNotificationThread Reviewed-by: dholmes, kevinw, sspitsyn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/20381 From duke at openjdk.org Wed Jul 31 21:38:46 2024 From: duke at openjdk.org (Henry Lin) Date: Wed, 31 Jul 2024 21:38:46 GMT Subject: RFR: 8337517: Redacted Heap Dumps Message-ID: Adds a command line option `-redact` to `jcmd`, `redact` to `jmap` and `-XX:+HeapDumpRedacted` enabling redacted heap dumps. When enabled, the output binary heap dump has zeroes written out in place of the original primitive values in the object fields. There is a new jtreg test `heapDumpRedactedTest.java` that tests that the fields are properly redacted. ------------- Commit messages: - remove whitespace - fix array redact and format - add jmap redact - changed heapDumper.cpp dump function to take in redact - add redact option to jcmd line - formatting - redacted heap dump and test Changes: https://git.openjdk.org/jdk/pull/20409/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20409&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337517 Stats: 287 lines in 13 files changed: 176 ins; 12 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20409.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20409/head:pull/20409 PR: https://git.openjdk.org/jdk/pull/20409 From cjplummer at openjdk.org Wed Jul 31 22:47:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 31 Jul 2024 22:47:31 GMT Subject: RFR: 8311990: Two JDI tests may interfere with each other [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 19:55:54 GMT, Alex Menkov wrote: >> test/jdk/com/sun/jdi/JdwpListenTest.java line 54: >> >>> 52: // It's off by default as it causes test time increase and test interference (see JDK-8231915). >>> 53: private static boolean allowNegativeTesting = >>> 54: "true".equalsIgnoreCase(System.getProperty("JDI_ALLOW_NEGATIVE_TESTING")); >> >> That seems a strange name for a system property - it would normally be something like jdk.jdi.allowNegativeTesting. Is this style of naming being used elsewhere? > > Renamed as suggested. > IIRC we had `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual` some time ago. Other tests use "standard" naming > use.JTREG_TEST_THREAD_FACTORY is not actually a property used by the source. It is just something we add to the mach5 JVM args to show that the test task was done with JTREG_TEST_THREAD_FACTORY=Virtual. It's basically a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20362#discussion_r1699179887 From dcubed at openjdk.org Wed Jul 31 23:11:30 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 31 Jul 2024 23:11:30 GMT Subject: RFR: 8337473: Remove sun/management/jdp tests from ProblemList on Linux-aarch64, MacOSX In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 10:52:06 GMT, Kevin Walls wrote: > Problemlist update only, should be trivial: > > Remove problemlist entries for sun/management/jdp tests on MacOS and Linux. > > 8241865 was a failure last seen July 2022. > Was related to > 8241530 com/sun/jdi tests fail due to network issues on OSX 10.15 > Originally logged for macOS failures but Linux failures also seen. > > The tests all pass 20 times in a row on the affected platforms. > > They remain problemlisted for JDK-8308807 on AIX. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20402#pullrequestreview-2211276376 From cjplummer at openjdk.org Wed Jul 31 23:33:31 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 31 Jul 2024 23:33:31 GMT Subject: RFR: 8337517: Redacted Heap Dumps In-Reply-To: References: Message-ID: <9HbHl2ISdQgcMHVgD8diI1RdZsCTA-JoP29ONTLUTNA=.5cc5acb8-e102-48cc-a9f9-9020fa762011@github.com> On Wed, 31 Jul 2024 19:10:41 GMT, Henry Lin wrote: > Adds a command line option `-redact` to `jcmd`, `redact` to `jmap` and `-XX:+HeapDumpRedacted` enabling redacted heap dumps. When enabled, the output binary heap dump has zeroes written out in place of the original primitive values in the object fields. There is a new jtreg test `heapDumpRedactedTest.java` that tests that the fields are properly redacted. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 142: > 140: */ > 141: InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > 142: assert args.length <= 4; // includes null I'm pretty sure we've been down this path before, and allowing 4 args will result in newer versions of the JVM not working with older versions of the tool. See [JDK-8219721](https://bugs.openjdk.org/browse/JDK-8219721) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20409#discussion_r1699202345