From amenkov at openjdk.java.net Tue Feb 1 10:33:11 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 1 Feb 2022 10:33:11 GMT Subject: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2] In-Reply-To: References: Message-ID: <1S-60YrnGlAZxXus4nncTWUz6X5x8AiQvXJUmn8M3cg=.04bef46a-f7cd-44ed-9190-f115c637c109@github.com> On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more precisely known, allowing the objects to be collected before the test expects. This became an issue in the loom repo because it has changes that result in a full GC when the codecache is swept. This is fixed by using statics to reference the objects. Also, if a GC does happen, this seems to get rid of the Survivor region, so the test was updated to no longer check for it. >> >> I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use Reference.reachabilityFence() instead of static field. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7257 From lmesnik at openjdk.java.net Tue Feb 1 14:49:17 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Feb 2022 14:49:17 GMT Subject: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2] In-Reply-To: References: Message-ID: <4jb192JXLFZg3gfQphYBfe1_8YhEuSI9r_eNrvXLrdM=.39763001-9938-413d-aa6e-489b8eaeb215@github.com> On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more precisely known, allowing the objects to be collected before the test expects. This became an issue in the loom repo because it has changes that result in a full GC when the codecache is swept. This is fixed by using statics to reference the objects. Also, if a GC does happen, this seems to get rid of the Survivor region, so the test was updated to no longer check for it. >> >> I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use Reference.reachabilityFence() instead of static field. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7257 From rkennke at openjdk.java.net Tue Feb 1 14:51:30 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 1 Feb 2022 14:51:30 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Message-ID: We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. ------------- Commit messages: - 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Changes: https://git.openjdk.java.net/jdk/pull/7306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276990 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7306/head:pull/7306 PR: https://git.openjdk.java.net/jdk/pull/7306 From cjplummer at openjdk.java.net Tue Feb 1 16:01:39 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:01:39 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Message-ID: The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen. The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher. I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. ------------- Commit messages: - Minor changes to comments. - Check both eden and old gen for expected types. Changes: https://git.openjdk.java.net/jdk/pull/7295/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279662 Stats: 40 lines in 1 file changed: 22 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7295/head:pull/7295 PR: https://git.openjdk.java.net/jdk/pull/7295 From cjplummer at openjdk.java.net Tue Feb 1 16:03:20 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:03:20 GMT Subject: RFR: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered [v2] In-Reply-To: References: Message-ID: <8YGGRUocGpC_8tskqCbr3rZPWho4ANiLcz6f01LO-ew=.776948cd-2e50-4daf-b237-ad1958a7da75@github.com> On Fri, 28 Jan 2022 07:49:42 GMT, Chris Plummer wrote: >> When using -Xcomp, the liveness of some objects the test allocates is more precisely known, allowing the objects to be collected before the test expects. This became an issue in the loom repo because it has changes that result in a full GC when the codecache is swept. This is fixed by using statics to reference the objects. Also, if a GC does happen, this seems to get rid of the Survivor region, so the test was updated to no longer check for it. >> >> I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Use Reference.reachabilityFence() instead of static field. Thanks for the reviews Alex, Alan, and Leonid! ------------- PR: https://git.openjdk.java.net/jdk/pull/7257 From cjplummer at openjdk.java.net Tue Feb 1 16:04:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:04:18 GMT Subject: RFR: 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote: > The test does a "threadcontext -v -a", and from the following output determines the threadID of the SteadyStateThread: > > `Thread "SteadyStateThread" id=23 Address=0x000001dc51749420` > > It then tries threadcontext on this id, but it fails: > > > + threadcontext -v 23 > Couldn't find thread 23 > > > This only happens on Windows. It turns out that each time you attach on Window, the threadID for a thread can change. Some added diagnostic output showed that for the SteadyStateThread, it changed from 23 to 20, and there is no thread with an ID of 23. > > The only way to make this this part of the test work Windows as expected is to parse the output of "threadcontext -v -a" without first doing a detach, and then doing the "threadcontext -v 23" without having to attach again. Unfortunately the test infrastructure for Clhsdb tests (and specifically ClhsdbLauncher) don't make this easy to do this. You can't easily see the output without first detaching, and then attach again on the next command. For this reason I've chosen to not verify the output of the "threadcontext -v " part of the test when running on Windows. ClhsdbLauncher will still do the normal checks to make sure no exceptions or errors are present in the output. Thanks for the reviews David and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7259 From cjplummer at openjdk.java.net Tue Feb 1 16:04:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:04:18 GMT Subject: Integrated: 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote: > The test does a "threadcontext -v -a", and from the following output determines the threadID of the SteadyStateThread: > > `Thread "SteadyStateThread" id=23 Address=0x000001dc51749420` > > It then tries threadcontext on this id, but it fails: > > > + threadcontext -v 23 > Couldn't find thread 23 > > > This only happens on Windows. It turns out that each time you attach on Window, the threadID for a thread can change. Some added diagnostic output showed that for the SteadyStateThread, it changed from 23 to 20, and there is no thread with an ID of 23. > > The only way to make this this part of the test work Windows as expected is to parse the output of "threadcontext -v -a" without first doing a detach, and then doing the "threadcontext -v 23" without having to attach again. Unfortunately the test infrastructure for Clhsdb tests (and specifically ClhsdbLauncher) don't make this easy to do this. You can't easily see the output without first detaching, and then attach again on the next command. For this reason I've chosen to not verify the output of the "threadcontext -v " part of the test when running on Windows. ClhsdbLauncher will still do the normal checks to make sure no exceptions or errors are present in the output. This pull request has now been integrated. Changeset: 5080e815 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/5080e815b4385751734054b5f889c4d89cfcdeb4 Stats: 20 lines in 1 file changed: 12 ins; 4 del; 4 mod 8280770: serviceability/sa/ClhsdbThreadContext.java sometimes fails with 'Thread "SteadyStateThread"' missing from stdout/stderr Reviewed-by: sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7259 From cjplummer at openjdk.java.net Tue Feb 1 16:05:10 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:05:10 GMT Subject: RFR: 8280601: ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find() [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 22:50:47 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Guard against invalid CodeBlobs that may throw exceptions. > > Looks okay to me. > Thanks, > Serguei @sspitsyn Can re-review these changes? I made a few changes since your last review. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7217 From cjplummer at openjdk.java.net Tue Feb 1 16:06:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 16:06:15 GMT Subject: Integrated: 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 04:27:18 GMT, Chris Plummer wrote: > When using -Xcomp, the liveness of some objects the test allocates is more precisely known, allowing the objects to be collected before the test expects. This became an issue in the loom repo because it has changes that result in a full GC when the codecache is swept. This is fixed by using statics to reference the objects. Also, if a GC does happen, this seems to get rid of the Survivor region, so the test was updated to no longer check for it. > > I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. This pull request has now been integrated. Changeset: 4532c3a1 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/4532c3a1639af0b4ff8c4f42c3796fa73ca5be83 Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod 8280554: resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java can fail if GC is triggered Reviewed-by: alanb, amenkov, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7257 From prappo at openjdk.java.net Tue Feb 1 16:31:38 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 1 Feb 2022 16:31:38 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS Message-ID: While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/7311/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7311&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281057 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7311.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7311/head:pull/7311 PR: https://git.openjdk.java.net/jdk/pull/7311 From darcy at openjdk.java.net Tue Feb 1 17:34:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 17:34:10 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: <64qmLKz3G6wYRdnA0Y65Fho7oUZqint8EKD-a1GXkJY=.4536f347-7bcd-4d74-b6e3-01441cf41f2c@github.com> On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From iris at openjdk.java.net Tue Feb 1 17:45:12 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 1 Feb 2022 17:45:12 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From cjplummer at openjdk.java.net Tue Feb 1 19:29:11 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 19:29:11 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 14:44:43 GMT, Roman Kennke wrote: > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 240: > 238: } > 239: error = methodSignature(method, NULL, &request->methodSignature, NULL); > 240: if (error != JVMTI_ERROR_NONE) { Shouldn't this be done when the invoke has completed rather than at the start of the next invoke? Otherwise you potentially have one outstanding allocation for every thread, and you still have a leak when the thread exits. ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Tue Feb 1 19:36:09 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 1 Feb 2022 19:36:09 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 19:26:19 GMT, Chris Plummer wrote: > Shouldn't this be done when the invoke has completed rather than at the start of the next invoke? Otherwise you potentially have one outstanding allocation for every thread, and you still have a leak when the thread exits. Yes, perhaps. Please help me, where would be a good and reliable place to do that? Towards the end of invoker_doInvoke() ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From cjplummer at openjdk.java.net Tue Feb 1 19:58:10 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 19:58:10 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 19:33:22 GMT, Roman Kennke wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 240: >> >>> 238: } >>> 239: error = methodSignature(method, NULL, &request->methodSignature, NULL); >>> 240: if (error != JVMTI_ERROR_NONE) { >> >> Shouldn't this be done when the invoke has completed rather than at the start of the next invoke? Otherwise you potentially have one outstanding allocation for every thread, and you still have a leak when the thread exits. > >> Shouldn't this be done when the invoke has completed rather than at the start of the next invoke? Otherwise you potentially have one outstanding allocation for every thread, and you still have a leak when the thread exits. > > Yes, perhaps. Please help me, where would be a good and reliable place to do that? Towards the end of invoker_doInvoke() ? In `invoker_completeInvokeRequest()` this appears to be the last reference: ` jbyte returnType = methodSignature_returnTag(request->methodSignature);` I would suggest freeing outside of the `if (!detached)` block and setting it to `NULL`. You might want to add an assert for `NULL` where you are currently freeing the pointer. ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From sspitsyn at openjdk.java.net Tue Feb 1 22:35:10 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 1 Feb 2022 22:35:10 GMT Subject: RFR: 8280601: ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find() [v2] In-Reply-To: <4zjSMehr5HL2LRkf78nDFVUO6I5m9mO_tTkZ6RfYsL0=.591be5f9-a037-4fd3-b7a3-c7f26587a753@github.com> References: <4zjSMehr5HL2LRkf78nDFVUO6I5m9mO_tTkZ6RfYsL0=.591be5f9-a037-4fd3-b7a3-c7f26587a753@github.com> Message-ID: On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote: >> It's possible for an address to be in the codecache but not in any CodeBlob. Don't assert in this case. >> >> Also I ran into a couple of other asserts listed below. It looks like since dumping the threadcontext can result in using PointerFinder with fairly random addresses, it is doing a much better job of stress testing PointerFinder than is done by other tests. The root issue in all these asserts is that a random address in the codecache can either be outside of any CodeBlob, or can map to a CodeBlob that is not yet initialized or could even have been freed. PointerFinder and PointerLocation need to be prepared to handled these asserts, and any other exception thrown. >> >> sun.jvm.hotspot.utilities.AssertionFailure: found wrong CodeBlob >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlobUnsafe(CodeCache.java:140) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:138) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) >> >> sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:140) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Guard against invalid CodeBlobs that may throw exceptions. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7217 From cjplummer at openjdk.java.net Tue Feb 1 22:49:11 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 22:49:11 GMT Subject: RFR: 8280601: ClhsdbThreadContext.java test is triggering codecache related assert in PointerFinder.find() [v2] In-Reply-To: <4zjSMehr5HL2LRkf78nDFVUO6I5m9mO_tTkZ6RfYsL0=.591be5f9-a037-4fd3-b7a3-c7f26587a753@github.com> References: <4zjSMehr5HL2LRkf78nDFVUO6I5m9mO_tTkZ6RfYsL0=.591be5f9-a037-4fd3-b7a3-c7f26587a753@github.com> Message-ID: On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote: >> It's possible for an address to be in the codecache but not in any CodeBlob. Don't assert in this case. >> >> Also I ran into a couple of other asserts listed below. It looks like since dumping the threadcontext can result in using PointerFinder with fairly random addresses, it is doing a much better job of stress testing PointerFinder than is done by other tests. The root issue in all these asserts is that a random address in the codecache can either be outside of any CodeBlob, or can map to a CodeBlob that is not yet initialized or could even have been freed. PointerFinder and PointerLocation need to be prepared to handled these asserts, and any other exception thrown. >> >> sun.jvm.hotspot.utilities.AssertionFailure: found wrong CodeBlob >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlobUnsafe(CodeCache.java:140) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:138) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) >> >> sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:140) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Guard against invalid CodeBlobs that may throw exceptions. Thanks Serguei and Kevin! ------------- PR: https://git.openjdk.java.net/jdk/pull/7217 From cjplummer at openjdk.java.net Tue Feb 1 23:06:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Feb 2022 23:06:15 GMT Subject: Integrated: 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 22:07:37 GMT, Chris Plummer wrote: > It's possible for an address to be in the codecache but not in any CodeBlob. Don't assert in this case. > > Also I ran into a couple of other asserts listed below. It looks like since dumping the threadcontext can result in using PointerFinder with fairly random addresses, it is doing a much better job of stress testing PointerFinder than is done by other tests. The root issue in all these asserts is that a random address in the codecache can either be outside of any CodeBlob, or can map to a CodeBlob that is not yet initialized or could even have been freed. PointerFinder and PointerLocation need to be prepared to handled these asserts, and any other exception thrown. > > sun.jvm.hotspot.utilities.AssertionFailure: found wrong CodeBlob > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlobUnsafe(CodeCache.java:140) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:138) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > > sun.jvm.hotspot.utilities.AssertionFailure: Should have found CodeBlob > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:140) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$46.doit(CommandProcessor.java:1702) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2215) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2185) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2056) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) This pull request has now been integrated. Changeset: 85d839fb Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/85d839fb4f3f820d130ea95f9a54ae137a95c20a Stats: 34 lines in 2 files changed: 20 ins; 5 del; 9 mod 8280601: ClhsdbThreadContext.java test is triggering codecache related asserts Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7217 From sspitsyn at openjdk.java.net Tue Feb 1 23:10:08 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 1 Feb 2022 23:10:08 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v4] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 11:32:18 GMT, Alex Menkov wrote: >> Changes: >> - ClassFileReconstituter is updated to restore "MethodParameters" attribute; >> - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); >> - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated per Chris feedback Marked as reviewed by sspitsyn (Reviewer). test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java line 101: > 99: > 100: // Prints and verifies MethodParameters attribute using reflection. > 101: private void verifyMethodParams(boolean expectedPresent, String... expectedNames) throws Throwable { Just a side comment, no intention to insist... I think, a generalization with the `expectedPresent` parameter adds a little bit of complexity. It feels that refactoring it into two methods - one for expected and another for non-expected would be more clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/7180 From sspitsyn at openjdk.java.net Wed Feb 2 00:17:10 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 00:17:10 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote: > The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen. > > The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher. > > I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. Looks reasonable to me. There is minor duplication but it is okay as there is no good way to get rid of it. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7295 From cjplummer at openjdk.java.net Wed Feb 2 00:33:14 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 00:33:14 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 00:14:06 GMT, Serguei Spitsyn wrote: > There is minor duplication but it is okay as there is no good way to get rid of it. I considered a loop or common method, but it seemed not to be worth it and likely less readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/7295 From sspitsyn at openjdk.java.net Wed Feb 2 02:12:05 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 02:12:05 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote: > The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen. > > The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher. > > I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. Agreed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7295 From kevinw at openjdk.java.net Wed Feb 2 09:52:11 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 2 Feb 2022 09:52:11 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote: > The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen. > > The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher. > > I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. Looks good. For the scanoops for a type, it seems like a reasonable assumption that there will be a String in the old gen! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/7295 From prappo at openjdk.java.net Wed Feb 2 10:01:06 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Feb 2022 10:01:06 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: <1V1_jhMx07iBPq8rzhWP2pwNkb8lBNpeqP3jzA06lf0=.79432eb1-3bf4-4d28-acb7-f5c07bf1f0c4@github.com> On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. I would appreciate it if serviceability and hotspot could review this PR too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From kevinw at openjdk.java.net Wed Feb 2 11:00:22 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 2 Feb 2022 11:00:22 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal Message-ID: Policy settings are no longer required to run jstatd. This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt And a copy of the new text rendered by man: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt ------------- Commit messages: - 8281049: man page update for jstatd Security Manager dependency removal Changes: https://git.openjdk.java.net/jdk/pull/7320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281049 Stats: 16 lines in 1 file changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7320/head:pull/7320 PR: https://git.openjdk.java.net/jdk/pull/7320 From amenkov at openjdk.java.net Wed Feb 2 12:03:47 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 2 Feb 2022 12:03:47 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v5] In-Reply-To: References: Message-ID: > Changes: > - ClassFileReconstituter is updated to restore "MethodParameters" attribute; > - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); > - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Split verification of presence and absence of the parameter names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7180/files - new: https://git.openjdk.java.net/jdk/pull/7180/files/17f4b10d..0f80f765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7180&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7180&range=03-04 Stats: 25 lines in 1 file changed: 13 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7180.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7180/head:pull/7180 PR: https://git.openjdk.java.net/jdk/pull/7180 From amenkov at openjdk.java.net Wed Feb 2 12:03:49 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 2 Feb 2022 12:03:49 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v4] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 23:06:47 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated per Chris feedback > > test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java line 101: > >> 99: >> 100: // Prints and verifies MethodParameters attribute using reflection. >> 101: private void verifyMethodParams(boolean expectedPresent, String... expectedNames) throws Throwable { > > Just a side comment, no intention to insist... > I think, a generalization with the `expectedPresent` parameter adds a little bit of complexity. > It feels that refactoring it into two methods - one for expected and another for non-expected would be more clear. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7180 From dholmes at openjdk.java.net Wed Feb 2 12:08:06 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Feb 2022 12:08:06 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670: > 668: * modifier is ignored for this test. > 669: * > 670: * See JLS 8.4.8.1 (without transitivity) and 8.4.8.4 Any idea what the "(without transitivity)" is referring to here and elsewhere? ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From dholmes at openjdk.java.net Wed Feb 2 12:14:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Feb 2022 12:14:04 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. Hi Pavel, All the section number changes look good and accurate. I have one query above, and also spotted one existing comment that is not correct. Thanks, David src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793: > 1791: } > 1792: > 1793: // Error if static method overrides instance method (JLS 8.4.8.2). "overrides" should be "hides" ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7311 From prappo at openjdk.java.net Wed Feb 2 12:34:05 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Feb 2022 12:34:05 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:04:29 GMT, David Holmes wrote: >> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. >> >> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670: > >> 668: * modifier is ignored for this test. >> 669: * >> 670: * See JLS 8.4.8.1 (without transitivity) and 8.4.8.4 > > Any idea what the "(without transitivity)" is referring to here and elsewhere? My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From prappo at openjdk.java.net Wed Feb 2 12:46:05 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Feb 2022 12:46:05 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:06:39 GMT, David Holmes wrote: >> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. >> >> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793: > >> 1791: } >> 1792: >> 1793: // Error if static method overrides instance method (JLS 8.4.8.2). > > "overrides" should be "hides" Although you seem to be correct, the error messages and the code around operate using the term "override": // Error if static method overrides instance method (JLS 8.4.8.2). if ((m.flags() & STATIC) != 0 && (other.flags() & STATIC) == 0) { log.error(TreeInfo.diagnosticPositionFor(m, tree), Errors.OverrideStatic(cannotOverride(m, other))); m.flags_field |= BAD_OVERRIDE; return; } // Error if instance method overrides static or final // method (JLS 8.4.8.1). if ((other.flags() & FINAL) != 0 || (m.flags() & STATIC) == 0 && (other.flags() & STATIC) != 0) { log.error(TreeInfo.diagnosticPositionFor(m, tree), Errors.OverrideMeth(cannotOverride(m, other), asFlagSet(other.flags() & (FINAL | STATIC)))); m.flags_field |= BAD_OVERRIDE; return; } /** * compiler.err.override.static=\ * {0}\n\ * overriding method is static */ public static Error OverrideStatic(Fragment arg0) { return new Error("compiler", "override.static", arg0); } Compiler folk, what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From david.holmes at oracle.com Wed Feb 2 13:39:38 2022 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Feb 2022 23:39:38 +1000 Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On 2/02/2022 10:46 pm, Pavel Rappo wrote: > On Wed, 2 Feb 2022 12:06:39 GMT, David Holmes wrote: > >>> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. >>> >>> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. >> >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793: >> >>> 1791: } >>> 1792: >>> 1793: // Error if static method overrides instance method (JLS 8.4.8.2). >> >> "overrides" should be "hides" > > Although you seem to be correct, the error messages and the code around operate using the term "override": Ah yes, I can see now that "overrides" is (incorrectly) used all through this code and even in the error messages. It is a subtle distinction. Cheers, David ----- > // Error if static method overrides instance method (JLS 8.4.8.2). > if ((m.flags() & STATIC) != 0 && > (other.flags() & STATIC) == 0) { > log.error(TreeInfo.diagnosticPositionFor(m, tree), > Errors.OverrideStatic(cannotOverride(m, other))); > m.flags_field |= BAD_OVERRIDE; > return; > } > > // Error if instance method overrides static or final > // method (JLS 8.4.8.1). > if ((other.flags() & FINAL) != 0 || > (m.flags() & STATIC) == 0 && > (other.flags() & STATIC) != 0) { > log.error(TreeInfo.diagnosticPositionFor(m, tree), > Errors.OverrideMeth(cannotOverride(m, other), > asFlagSet(other.flags() & (FINAL | STATIC)))); > m.flags_field |= BAD_OVERRIDE; > return; > } > > > /** > * compiler.err.override.static=\ > * {0}\n\ > * overriding method is static > */ > public static Error OverrideStatic(Fragment arg0) { > return new Error("compiler", "override.static", arg0); > } > > Compiler folk, what do you think? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7311 From rkennke at openjdk.java.net Wed Feb 2 13:40:31 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 13:40:31 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v2] In-Reply-To: References: Message-ID: > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Deallocate methodSignature after completed request ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7306/files - new: https://git.openjdk.java.net/jdk/pull/7306/files/52eac5b2..4b62941b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7306/head:pull/7306 PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Wed Feb 2 13:40:33 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 13:40:33 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v2] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 19:55:15 GMT, Chris Plummer wrote: > In `invoker_completeInvokeRequest()` this appears to be the last reference: > > ` jbyte returnType = methodSignature_returnTag(request->methodSignature);` > > I would suggest freeing outside of the `if (!detached)` block and setting it to `NULL`. You might want to add an assert for `NULL` where you are currently freeing the pointer. Alright, that seems sensible. Thank you! I am not 100% if methodSignature can always be expected to be != NULL there, as I asserted. WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Wed Feb 2 14:17:42 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 14:17:42 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v3] In-Reply-To: References: Message-ID: <1WnK7tfvlufqT54aU-gqTvJ3qHRvChhJET6geDsgzKU=.8d6cfac1-7b45-4657-b9d2-7051ce19e80b@github.com> > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. > > Testing: > - [x] tier1 > - [ ] tier2 > - [ ] tier3 > - [ ] Customer confirming fix of memory leak Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Deallocate methodSignature in deleteGlobalArgumentRefs() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7306/files - new: https://git.openjdk.java.net/jdk/pull/7306/files/4b62941b..a273574b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=01-02 Stats: 9 lines in 1 file changed: 4 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7306/head:pull/7306 PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Wed Feb 2 14:17:43 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 14:17:43 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v3] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 13:37:15 GMT, Roman Kennke wrote: >> In `invoker_completeInvokeRequest()` this appears to be the last reference: >> >> ` jbyte returnType = methodSignature_returnTag(request->methodSignature);` >> >> I would suggest freeing outside of the `if (!detached)` block and setting it to `NULL`. You might want to add an assert for `NULL` where you are currently freeing the pointer. > >> In `invoker_completeInvokeRequest()` this appears to be the last reference: >> >> ` jbyte returnType = methodSignature_returnTag(request->methodSignature);` >> >> I would suggest freeing outside of the `if (!detached)` block and setting it to `NULL`. You might want to add an assert for `NULL` where you are currently freeing the pointer. > > Alright, that seems sensible. Thank you! > I am not 100% if methodSignature can always be expected to be != NULL there, as I asserted. WDYT? We need to deallocate the methodSignature after deleteGlobalArgumentRefs() because that method accesses it. Or better yet, deallocate it there, because the only point of deleteGlobalArgumentRefs() seems to reset the methodSignature anyway. And that method seems to assume methodSignature != NULL, so we can do the same. WDYT? The change passes tier1 tests (including com/sun/jdi which exercises this code). ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From mcimadamore at openjdk.java.net Wed Feb 2 14:41:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Feb 2022 14:41:11 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:31:04 GMT, Pavel Rappo wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670: >> >>> 668: * modifier is ignored for this test. >>> 669: * >>> 670: * See JLS 8.4.8.1 (without transitivity) and 8.4.8.4 >> >> Any idea what the "(without transitivity)" is referring to here and elsewhere? > > My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? First, this class contains many references to 8.4.6.x - which should really be 8.4.8.x - not just this one. I'm not 100% sure about the "without transitivity" comment, but if I had to guess I'd say that it refers to the fact that the checks described in 8.4.8.3 are missing from this routine. More specifically, this section: It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true: * m1 and m2 have the same name. * m2 is accessible (?6.6) from C. * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A. * The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly). <---------- As you can see, the last bullet introduces some sort of global requirement across the inheritance chain; this constraint was necessary after Java 5, as generics require the introduction of bridge methods, and it is possible, in some extreme cases, for a subclass to override (accidentally) a bridge method. The JLS doesn't say the word "bridge method" anywhere, but this is what this check morally does. Now, in an early version of the Java compiler (5 and 6, IIRC), we used to check for clashes with bridge methods at code generation time. So, the checks in the compiler frontend, such as Symbol::overrides did not really have to concerb with that expensive side of the override check. But, as the implementation matured, it became clearer that (a) the code-generation clash check was not enough to detect all problematic cases and (b) detecting clashes at code generation time was *too late*, especially for clients of the compiler API which might only run the "analyze" step. For these reasons, staring from Java 7, the frontend also has a more expensive check which supports 8.4.8.3 in full (Check::checkOverrideClashes). Of course, not being the author of that comment, this is only my best guess as to what that could mean :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From prappo at openjdk.java.net Wed Feb 2 15:44:11 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 2 Feb 2022 15:44:11 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 14:37:39 GMT, Maurizio Cimadamore wrote: >> My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore? > > First, this class contains many references to 8.4.6.x - which should really be 8.4.8.x - not just this one. > > I'm not 100% sure about the "without transitivity" comment, but if I had to guess I'd say that it refers to the fact that the checks described in 8.4.8.3 are missing from this routine. More specifically, this section: > > > It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true: > * m1 and m2 have the same name. > * m2 is accessible (?6.6) from C. > * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A. > * The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly). <---------- > > As you can see, the last bullet introduces some sort of global requirement across the inheritance chain; this constraint was necessary after Java 5, as generics require the introduction of bridge methods, and it is possible, in some extreme cases, for a subclass to override (accidentally) a bridge method. The JLS doesn't say the word "bridge method" anywhere, but this is what this check morally does. > > Now, in an early version of the Java compiler (5 and 6, IIRC), we used to check for clashes with bridge methods at code generation time. So, the checks in the compiler frontend, such as Symbol::overrides did not really have to concerb with that expensive side of the override check. > > But, as the implementation matured, it became clearer that (a) the code-generation clash check was not enough to detect all problematic cases and (b) detecting clashes at code generation time was *too late*, especially for clients of the compiler API which might only run the "analyze" step. For these reasons, staring from Java 7, the frontend also has a more expensive check which supports 8.4.8.3 in full (Check::checkOverrideClashes). > > Of course, not being the author of that comment, this is only my best guess as to what that could mean :-) FWIW, I found a related bug: https://bugs.openjdk.java.net/browse/JDK-4362349. It might be responsible for that "(without transitivity)" caveat. ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From cjplummer at openjdk.java.net Wed Feb 2 16:24:11 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 16:24:11 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 09:49:26 GMT, Kevin Walls wrote: > For the scanoops for a type, it seems like a reasonable assumption that there will be a String in the old gen! Actually it's not, and that's why I check the Eden gen. If a GC is not triggered, the old gen will be empty. It not actually guaranteed that a String will be in the Eden gen either, but at least at the moment that appears to be the case whether or not a GC is triggered. ------------- PR: https://git.openjdk.java.net/jdk/pull/7295 From rkennke at openjdk.java.net Wed Feb 2 17:08:37 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 17:08:37 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v4] In-Reply-To: References: Message-ID: > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. > > Testing: > - [x] tier1 > - [x] tier2 > - [ ] tier3 > - [x] Customer confirming fix of memory leak Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Preserve methodSignature_init(), we need the cursor later ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7306/files - new: https://git.openjdk.java.net/jdk/pull/7306/files/a273574b..812ad324 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7306/head:pull/7306 PR: https://git.openjdk.java.net/jdk/pull/7306 From cjplummer at openjdk.java.net Wed Feb 2 18:49:08 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 18:49:08 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v4] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 14:11:45 GMT, Roman Kennke wrote: >>> In `invoker_completeInvokeRequest()` this appears to be the last reference: >>> >>> ` jbyte returnType = methodSignature_returnTag(request->methodSignature);` >>> >>> I would suggest freeing outside of the `if (!detached)` block and setting it to `NULL`. You might want to add an assert for `NULL` where you are currently freeing the pointer. >> >> Alright, that seems sensible. Thank you! >> I am not 100% if methodSignature can always be expected to be != NULL there, as I asserted. WDYT? > > We need to deallocate the methodSignature after deleteGlobalArgumentRefs() because that method accesses it. Or better yet, deallocate it there, because the only point of deleteGlobalArgumentRefs() seems to reset the methodSignature anyway. And that method seems to assume methodSignature != NULL, so we can do the same. WDYT? The change passes tier1 tests (including com/sun/jdi which exercises this code). Are you still hitting the assert in fillInvokeRequest()? I'm not sure why it would ever not be NULL there. It's probably worth investigating some more. Otherwise you need to remove the assert, and possibly still have a leak. ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Wed Feb 2 18:49:08 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 18:49:08 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v4] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 18:43:46 GMT, Chris Plummer wrote: > Are you still hitting the assert in fillInvokeRequest()? I'm not sure why it would ever not be NULL there. It's probably worth investigating some more. Otherwise you need to remove the assert, and possibly still have a leak. No, the latest version seems good and passes tier1-3 and customer confirmed that it fixes the memory leak. ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From cjplummer at openjdk.java.net Wed Feb 2 18:57:17 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 18:57:17 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v5] In-Reply-To: References: Message-ID: <5Y4VcUKw8qdC48AcC7rmZIPxyfe_gxjC9rBLNH3lyOA=.e492154d-b9a7-418a-b95d-1bfb242d96fc@github.com> On Wed, 2 Feb 2022 12:03:47 GMT, Alex Menkov wrote: >> Changes: >> - ClassFileReconstituter is updated to restore "MethodParameters" attribute; >> - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); >> - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Split verification of presence and absence of the parameter names Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7180 From cjplummer at openjdk.java.net Wed Feb 2 19:01:03 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 19:01:03 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v4] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 18:45:33 GMT, Roman Kennke wrote: >> Are you still hitting the assert in fillInvokeRequest()? I'm not sure why it would ever not be NULL there. It's probably worth investigating some more. Otherwise you need to remove the assert, and possibly still have a leak. > >> Are you still hitting the assert in fillInvokeRequest()? I'm not sure why it would ever not be NULL there. It's probably worth investigating some more. Otherwise you need to remove the assert, and possibly still have a leak. > > No, the latest version seems good and passes tier1-3 and customer confirmed that it fixes the memory leak. Ok. I think I prefer you to free the memory after calling `deleteGlobalArgumentRefs()` since `deleteGlobalArgumentRefs()` is really all about releasing JNI global refs, not freeing other allocated memory. ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From kevinw at openjdk.java.net Wed Feb 2 19:32:12 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 2 Feb 2022 19:32:12 GMT Subject: RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 16:21:05 GMT, Chris Plummer wrote: > Actually it's not, and that's why I check the Eden gen. Yes sorry, should have said it's a good bet to find a String when only checking one generation. Carry on... ------------- PR: https://git.openjdk.java.net/jdk/pull/7295 From rkennke at openjdk.java.net Wed Feb 2 19:34:14 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 19:34:14 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v5] In-Reply-To: References: Message-ID: > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. > > Testing: > - [x] tier1 > - [x] tier2 > - [ ] tier3 > - [x] Customer confirming fix of memory leak Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move freeing of methodSignature after deleteGlobalArgumentRefs() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7306/files - new: https://git.openjdk.java.net/jdk/pull/7306/files/812ad324..b3e7a529 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7306&range=03-04 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7306/head:pull/7306 PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Wed Feb 2 19:46:04 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 19:46:04 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v5] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 18:58:23 GMT, Chris Plummer wrote: >>> Are you still hitting the assert in fillInvokeRequest()? I'm not sure why it would ever not be NULL there. It's probably worth investigating some more. Otherwise you need to remove the assert, and possibly still have a leak. >> >> No, the latest version seems good and passes tier1-3 and customer confirmed that it fixes the memory leak. > > Ok. I think I prefer you to free the memory after calling `deleteGlobalArgumentRefs()` since `deleteGlobalArgumentRefs()` is really all about releasing JNI global refs, not freeing other allocated memory. Ok, I've moved it back to after the call to deleteGlobalArgumentRefs(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From sspitsyn at openjdk.java.net Wed Feb 2 20:15:12 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 20:15:12 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v5] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:03:47 GMT, Alex Menkov wrote: >> Changes: >> - ClassFileReconstituter is updated to restore "MethodParameters" attribute; >> - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); >> - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Split verification of presence and absence of the parameter names The update looks good to me. I've inlined just one minor comment about naming. Thanks, Serguei test/jdk/java/lang/instrument/RetransformWithMethodParametersTest.java line 100: > 98: } > 99: > 100: private Parameter[] getTargetClassParameters() throws ClassNotFoundException { Should this be named getTargetMethodParameters instead? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7180 From sspitsyn at openjdk.java.net Wed Feb 2 20:20:07 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 20:20:07 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v5] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 19:34:14 GMT, Roman Kennke wrote: >> We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. >> >> AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. >> >> Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 >> - [x] Customer confirming fix of memory leak > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move freeing of methodSignature after deleteGlobalArgumentRefs() Hi Roman, It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7306 From kevinw at openjdk.java.net Wed Feb 2 21:42:40 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 2 Feb 2022 21:42:40 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library Message-ID: Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). ------------- Commit messages: - 8272777: Clean up remaining AccessController warnings in test library Changes: https://git.openjdk.java.net/jdk/pull/7328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272777 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7328/head:pull/7328 PR: https://git.openjdk.java.net/jdk/pull/7328 From cjplummer at openjdk.java.net Wed Feb 2 21:47:14 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 21:47:14 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v5] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 19:34:14 GMT, Roman Kennke wrote: >> We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. >> >> AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. >> >> Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 >> - [x] Customer confirming fix of memory leak > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move freeing of methodSignature after deleteGlobalArgumentRefs() Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From cjplummer at openjdk.java.net Wed Feb 2 21:54:19 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 21:54:19 GMT Subject: Integrated: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC In-Reply-To: References: Message-ID: <4NTmqZOfJHgeJqIHOgSnu0fJYx8GeHN2p1FoQ3zCAHs=.31c03a97-d7b3-4d18-9d78-632e9ec4cb97@github.com> On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote: > The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen. > > The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher. > > I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk. This pull request has now been integrated. Changeset: fe0118f8 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/fe0118f8040ce7e5e3d605942443e3a5d442fa92 Stats: 40 lines in 1 file changed: 22 ins; 2 del; 16 mod 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/7295 From rriggs at openjdk.java.net Wed Feb 2 22:20:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Feb 2022 22:20:06 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: <_L4Gi3dFyz96bvNUHDkT7IuStFCz3NzUG_gRvtvemNA=.ac833bfc-d84a-4ce0-9053-ed9b515858cc@github.com> On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From cjplummer at openjdk.java.net Wed Feb 2 22:44:06 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 22:44:06 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 10:54:19 GMT, Kevin Walls wrote: > Policy settings are no longer required to run jstatd. > > This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt > > And a copy of the new text rendered by man: > https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt src/jdk.jstatd/share/man/jstatd.1 line 124: > 122: .PP > 123: As RMI is in use, the jstatd server uses an ObjectInputFilter to allow > 124: only essential classes to be deserialized. How about: For security purposes, the jstatd server uses an RMI ObjectInputFilter to allow only essential classes to be deserialized. ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From cjplummer at openjdk.java.net Wed Feb 2 22:48:12 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Feb 2022 22:48:12 GMT Subject: RFR: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. `com/sun/jdi/ReferenceType.java` changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7311 From sspitsyn at openjdk.java.net Wed Feb 2 22:56:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Feb 2022 22:56:16 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From rkennke at openjdk.java.net Thu Feb 3 07:28:13 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 3 Feb 2022 07:28:13 GMT Subject: RFR: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations [v5] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 19:34:14 GMT, Roman Kennke wrote: >> We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. >> >> AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. >> >> Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [ ] tier3 >> - [x] Customer confirming fix of memory leak > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move freeing of methodSignature after deleteGlobalArgumentRefs() Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From rkennke at openjdk.java.net Thu Feb 3 07:28:14 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 3 Feb 2022 07:28:14 GMT Subject: Integrated: 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations In-Reply-To: References: Message-ID: <0TqNR-PaekH_Ey8oIdDEmvDNvbtle5xz9n2WrHNT0gU=.9c834f8b-4206-4822-a3ce-b760156376ff@github.com> On Tue, 1 Feb 2022 14:44:43 GMT, Roman Kennke wrote: > We observe a native memory leak when repeating JDI operations from Eclipse in a debuggee JVM. See bug report for details. > > AFAICT, this happens because we override methodSignature of a possible pre-existing request object. I am not sure if there is a better place to deallocate the signature. > > Also, I am not sure how to make an automated test for this. We (that is, the customer that reported the problem) verified that the memory leak disappears with the fix. > > Testing: > - [x] tier1 > - [x] tier2 > - [ ] tier3 > - [x] Customer confirming fix of memory leak This pull request has now been integrated. Changeset: 5ab22e88 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/5ab22e88da8d79f9e19e8afffdd06206f42bab94 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8276990: Memory leak in invoker.c fillInvokeRequest() during JDI operations Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/7306 From kevinw at openjdk.java.net Thu Feb 3 09:51:55 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 09:51:55 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v2] In-Reply-To: References: Message-ID: > Policy settings are no longer required to run jstatd. > > This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt > > And a copy of the new text rendered by man: > https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7320/files - new: https://git.openjdk.java.net/jdk/pull/7320/files/9becb618..1e082f9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7320&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7320/head:pull/7320 PR: https://git.openjdk.java.net/jdk/pull/7320 From kevinw at openjdk.java.net Thu Feb 3 09:51:57 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 09:51:57 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 22:41:02 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Update > > src/jdk.jstatd/share/man/jstatd.1 line 124: > >> 122: .PP >> 123: As RMI is in use, the jstatd server uses an ObjectInputFilter to allow >> 124: only essential classes to be deserialized. > > How about: > > For security purposes, the jstatd server uses an RMI ObjectInputFilter to allow only essential classes to be deserialized. Yes, sounds good - updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From kevinw at openjdk.java.net Thu Feb 3 10:14:14 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 10:14:14 GMT Subject: RFR: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). Thanks Roger and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From kevinw at openjdk.java.net Thu Feb 3 10:14:14 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 10:14:14 GMT Subject: Integrated: 8272777: Clean up remaining AccessController warnings in test library In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote: > Reduce noise in test output by adding the @SuppressWarnings("removal") annotation (which has already been widely applied). This pull request has now been integrated. Changeset: 63a00a0d Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/63a00a0df24b154ef459936dbd69bcd2f0626235 Stats: 5 lines in 3 files changed: 3 ins; 0 del; 2 mod 8272777: Clean up remaining AccessController warnings in test library Reviewed-by: rriggs, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7328 From amenkov at openjdk.java.net Thu Feb 3 11:28:48 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 3 Feb 2022 11:28:48 GMT Subject: RFR: 8240908: RetransformClass does not know about MethodParameters attribute [v6] In-Reply-To: References: Message-ID: > Changes: > - ClassFileReconstituter is updated to restore "MethodParameters" attribute; > - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); > - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: renamed getTargetClassParameters method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7180/files - new: https://git.openjdk.java.net/jdk/pull/7180/files/0f80f765..3ea14e42 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7180&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7180&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7180.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7180/head:pull/7180 PR: https://git.openjdk.java.net/jdk/pull/7180 From prappo at openjdk.java.net Thu Feb 3 14:58:12 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Thu, 3 Feb 2022 14:58:12 GMT Subject: Integrated: 8281057: Fix doc references to overriding in JLS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo wrote: > While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**. > > Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections. This pull request has now been integrated. Changeset: 1f926609 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/1f926609372c9b80dde831a014310a3729768c92 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod 8281057: Fix doc references to overriding in JLS Reviewed-by: darcy, iris, dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/7311 From amenkov at openjdk.java.net Thu Feb 3 15:55:12 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 3 Feb 2022 15:55:12 GMT Subject: Integrated: 8240908: RetransformClass does not know about MethodParameters attribute In-Reply-To: References: Message-ID: <7rh3sa5syb4AwtoKn8_ssklX5x2jRJ48c5q_7fbGOSY=.05c81fa5-8a00-4b72-86f7-acec87178130@github.com> On Fri, 21 Jan 2022 15:40:07 GMT, Alex Menkov wrote: > Changes: > - ClassFileReconstituter is updated to restore "MethodParameters" attribute; > - handling of the attribute in VM_RedefineClasses is moved to be consistent with other code (like local variable table); > - copied ClassTransformer class (from test/jdk/com/sun/jdi/lib/jdb) to /test/lib as it's used by tests from hotspot and jdk (and also by test from Valhalla repo); Will file a follow up issues to updates tests and remove the class from test/jdk/com/sun/jdi/lib/jdb This pull request has now been integrated. Changeset: 86c24b31 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/86c24b319ed5e2f0097cfb4b1afe2eb358eb5f75 Stats: 320 lines in 5 files changed: 300 ins; 15 del; 5 mod 8240908: RetransformClass does not know about MethodParameters attribute Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7180 From cjplummer at openjdk.java.net Thu Feb 3 16:43:04 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 3 Feb 2022 16:43:04 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v2] In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 09:51:55 GMT, Kevin Walls wrote: >> Policy settings are no longer required to run jstatd. >> >> This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt >> >> And a copy of the new text rendered by man: >> https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.jstatd/share/man/jstatd.1 line 124: > 122: .PP > 123: For security purposes, the jstatd server uses an RMI ObjectInputFilter > 124: to allow only essential classes to be deserialized. It looks like some formatting is now missing around `jstatd`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From kevinw at openjdk.java.net Thu Feb 3 17:44:47 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 17:44:47 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v3] In-Reply-To: References: Message-ID: <4fe5EMNJ8M6p2EuDf-USLrgFoyVNRMI3ptpdXkWkhXk=.72ec6e15-2057-43f9-bd60-944b29bfc6b4@github.com> > Policy settings are no longer required to run jstatd. > > This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt > > And a copy of the new text rendered by man: > https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Quotes/bold ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7320/files - new: https://git.openjdk.java.net/jdk/pull/7320/files/1e082f9d..45ad90a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7320&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7320&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7320/head:pull/7320 PR: https://git.openjdk.java.net/jdk/pull/7320 From kevinw at openjdk.java.net Thu Feb 3 17:44:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 3 Feb 2022 17:44:49 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v2] In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 16:39:45 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Update > > src/jdk.jstatd/share/man/jstatd.1 line 124: > >> 122: .PP >> 123: For security purposes, the jstatd server uses an RMI ObjectInputFilter >> 124: to allow only essential classes to be deserialized. > > It looks like some formatting is now missing around `jstatd`. Right, missed the quotes we use around jstatd in other places. Added them in this update - I now see the word **jstatd** in bold in the man output like the other places. ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From amenkov at openjdk.java.net Fri Feb 4 11:25:25 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 4 Feb 2022 11:25:25 GMT Subject: RFR: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Message-ID: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> The test expects ClassFileReconstituter restores exactly the same bytes as original classbytes. This can be wrong if the class has more than 1 method (due to method sorting in the VM). MethodParametersTarget class had only 1 method (method1), but didn't have constructors. This caused declaration of implicit default constructor, so the class actually had 2 methods. The fix converts the method to constructor to avoid default constructor declaration. ------------- Commit messages: - Fixed indent - Converted target class method to ctor Changes: https://git.openjdk.java.net/jdk/pull/7345/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7345&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281243 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7345/head:pull/7345 PR: https://git.openjdk.java.net/jdk/pull/7345 From sspitsyn at openjdk.java.net Fri Feb 4 18:13:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 4 Feb 2022 18:13:16 GMT Subject: RFR: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing In-Reply-To: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> References: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> Message-ID: On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote: > The test expects ClassFileReconstituter restores exactly the same bytes as original classbytes. > This can be wrong if the class has more than 1 method (due to method sorting in the VM). > MethodParametersTarget class had only 1 method (method1), but didn't have constructors. This caused declaration of implicit default constructor, so the class actually had 2 methods. > The fix converts the method to constructor to avoid default constructor declaration. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7345 From dcubed at openjdk.java.net Fri Feb 4 18:21:09 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 4 Feb 2022 18:21:09 GMT Subject: RFR: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing In-Reply-To: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> References: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> Message-ID: <14tnnZUvKl7BHBPhif0krBt7gCntBd0oOw2gAAKHbAE=.b11a42d7-f8a0-43f2-bd24-17eee92f8459@github.com> On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote: > The test expects ClassFileReconstituter restores exactly the same bytes as original classbytes. > This can be wrong if the class has more than 1 method (due to method sorting in the VM). > MethodParametersTarget class had only 1 method (method1), but didn't have constructors. This caused declaration of implicit default constructor, so the class actually had 2 methods. > The fix converts the method to constructor to avoid default constructor declaration. Thumbs up on the changes. However, there's no details on how this fix was tested. Please clarify. So far this test failure has been seen intermittently in Tier3. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7345 From lmesnik at openjdk.java.net Fri Feb 4 18:38:07 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 4 Feb 2022 18:38:07 GMT Subject: RFR: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing In-Reply-To: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> References: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> Message-ID: On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote: > The test expects ClassFileReconstituter restores exactly the same bytes as original classbytes. > This can be wrong if the class has more than 1 method (due to method sorting in the VM). > MethodParametersTarget class had only 1 method (method1), but didn't have constructors. This caused declaration of implicit default constructor, so the class actually had 2 methods. > The fix converts the method to constructor to avoid default constructor declaration. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7345 From cjplummer at openjdk.java.net Fri Feb 4 20:23:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Feb 2022 20:23:15 GMT Subject: RFR: 8281049: man page update for jstatd Security Manager dependency removal [v3] In-Reply-To: <4fe5EMNJ8M6p2EuDf-USLrgFoyVNRMI3ptpdXkWkhXk=.72ec6e15-2057-43f9-bd60-944b29bfc6b4@github.com> References: <4fe5EMNJ8M6p2EuDf-USLrgFoyVNRMI3ptpdXkWkhXk=.72ec6e15-2057-43f9-bd60-944b29bfc6b4@github.com> Message-ID: <4W_pk8hxW5e-6l_Z-G5doGGrkP9uOKlFy8hZ0NvgUi8=.a30a7a91-9dcc-42e2-9dff-d632bd3e9e5d@github.com> On Thu, 3 Feb 2022 17:44:47 GMT, Kevin Walls wrote: >> Policy settings are no longer required to run jstatd. >> >> This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt >> >> And a copy of the new text rendered by man: >> https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Quotes/bold Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From kevinw at openjdk.java.net Fri Feb 4 21:27:12 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 4 Feb 2022 21:27:12 GMT Subject: Integrated: 8281049: man page update for jstatd Security Manager dependency removal In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 10:54:19 GMT, Kevin Walls wrote: > Policy settings are no longer required to run jstatd. > > This PR is the change to the source file src/jdk.jstatd/share/man/jstatd.1 and in case that's hard to read, here is a diff of the text as rendered by the man command: https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.diff.txt > > And a copy of the new text rendered by man: > https://cr.openjdk.java.net/~kevinw/8281049/jstatd.man.new.txt This pull request has now been integrated. Changeset: 48523b09 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/48523b090886f7b24ed4009f0c150efaa6f7b056 Stats: 16 lines in 1 file changed: 0 ins; 3 del; 13 mod 8281049: man page update for jstatd Security Manager dependency removal Reviewed-by: cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/7320 From amenkov at openjdk.java.net Mon Feb 7 09:12:12 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 7 Feb 2022 09:12:12 GMT Subject: RFR: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing In-Reply-To: <14tnnZUvKl7BHBPhif0krBt7gCntBd0oOw2gAAKHbAE=.b11a42d7-f8a0-43f2-bd24-17eee92f8459@github.com> References: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> <14tnnZUvKl7BHBPhif0krBt7gCntBd0oOw2gAAKHbAE=.b11a42d7-f8a0-43f2-bd24-17eee92f8459@github.com> Message-ID: <06NcY1rttwZBwf8MiiWYcZeR-SMq9o1OwGe0BOD9o9U=.16a05e3d-5230-4610-8dbf-5050b7b2cfe7@github.com> On Fri, 4 Feb 2022 18:17:33 GMT, Daniel D. Daugherty wrote: > Thumbs up on the changes. > > However, there's no details on how this fix was tested. Please clarify. So far this test failure has been seen intermittently in Tier3. Failure reports clearly show that the root cause is method sorting (ctor and method1 are in different order in original and reconstructed bytes), so I manually verified that now target class has the only method. Also I run the test with --test-repeat 100 on supported platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/7345 From amenkov at openjdk.java.net Mon Feb 7 09:12:14 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 7 Feb 2022 09:12:14 GMT Subject: Integrated: 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing In-Reply-To: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> References: <4EjzxUZLOlCd-IvJv_6sXvuE0yOAlp7fFTGS_IVJveA=.4d1b7059-571a-4347-bc53-129dc4e3459b@github.com> Message-ID: On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote: > The test expects ClassFileReconstituter restores exactly the same bytes as original classbytes. > This can be wrong if the class has more than 1 method (due to method sorting in the VM). > MethodParametersTarget class had only 1 method (method1), but didn't have constructors. This caused declaration of implicit default constructor, so the class actually had 2 methods. > The fix converts the method to constructor to avoid default constructor declaration. This pull request has now been integrated. Changeset: 95fd9d20 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/95fd9d20f329b15d68e613ec7f932254715e9130 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8281243: Test java/lang/instrument/RetransformWithMethodParametersTest.java is failing Reviewed-by: sspitsyn, dcubed, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7345 From kevinw at openjdk.java.net Mon Feb 7 11:42:27 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 11:42:27 GMT Subject: RFR: 8276680: Malformed Javadoc inline tags in JDK source in javax/management Message-ID: Trivial doc typo. Now I realise this javadoc for a package-private constructor isn't even in the standard generated docs. But you could choose to use different javadoc options. ------------- Commit messages: - 8276680: Malformed Javadoc inline tags in JDK source in javax/management Changes: https://git.openjdk.java.net/jdk/pull/7366/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276680 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7366/head:pull/7366 PR: https://git.openjdk.java.net/jdk/pull/7366 From kevinw at openjdk.java.net Mon Feb 7 15:47:22 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 15:47:22 GMT Subject: RFR: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Message-ID: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Test failed many years ago. Cannot provoke a failure today in hundreds of runs. Initial failure may have been specific to Solaris. ------------- Commit messages: - 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Changes: https://git.openjdk.java.net/jdk/pull/7369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281377 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7369/head:pull/7369 PR: https://git.openjdk.java.net/jdk/pull/7369 From sspitsyn at openjdk.java.net Mon Feb 7 17:20:09 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 7 Feb 2022 17:20:09 GMT Subject: RFR: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. In-Reply-To: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> References: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Message-ID: On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote: > Test failed many years ago. > Cannot provoke a failure today in hundreds of runs. > Initial failure may have been specific to Solaris. Hi Kevin, Looks good and trivial. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7369 From kevinw at openjdk.java.net Mon Feb 7 17:34:29 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 17:34:29 GMT Subject: RFR: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Message-ID: Trivial comment and exception text update, correcting a bug ID to make more sense. ------------- Commit messages: - 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Changes: https://git.openjdk.java.net/jdk/pull/7371/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7371&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6779701 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7371.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7371/head:pull/7371 PR: https://git.openjdk.java.net/jdk/pull/7371 From kevinw at openjdk.java.net Mon Feb 7 17:43:08 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 17:43:08 GMT Subject: RFR: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. In-Reply-To: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> References: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Message-ID: On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote: > Test failed many years ago. > Cannot provoke a failure today in hundreds of runs. > Initial failure may have been specific to Solaris. Thanks Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7369 From cjplummer at openjdk.java.net Mon Feb 7 17:43:08 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Feb 2022 17:43:08 GMT Subject: RFR: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. In-Reply-To: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> References: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Message-ID: <40Tsw8n2PLQMDBlT9xaFpS7iVt3O5Y4XLqqLuxYCocc=.4146888f-48da-48db-893b-bf9691e681fd@github.com> On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote: > Test failed many years ago. > Cannot provoke a failure today in hundreds of runs. > Initial failure may have been specific to Solaris. MixedDeadlock001.java was also reported as having failed in the CR. It was never problem listed, and apparently has been running fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7369 From kevinw at openjdk.java.net Mon Feb 7 17:43:08 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 17:43:08 GMT Subject: Integrated: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. In-Reply-To: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> References: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Message-ID: On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote: > Test failed many years ago. > Cannot provoke a failure today in hundreds of runs. > Initial failure may have been specific to Solaris. This pull request has now been integrated. Changeset: 1dfc94dd Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/1dfc94dd561f6a91ef3784fe28c83f839f8188c4 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7369 From cjplummer at openjdk.java.net Mon Feb 7 17:46:08 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 7 Feb 2022 17:46:08 GMT Subject: RFR: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 17:28:29 GMT, Kevin Walls wrote: > Trivial comment and exception text update, correcting a bug ID to make more sense. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7371 From dfuchs at openjdk.java.net Mon Feb 7 18:12:15 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Feb 2022 18:12:15 GMT Subject: RFR: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 17:28:29 GMT, Kevin Walls wrote: > Trivial comment and exception text update, correcting a bug ID to make more sense. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7371 From kevinw at openjdk.java.net Mon Feb 7 18:19:10 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 18:19:10 GMT Subject: RFR: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 17:28:29 GMT, Kevin Walls wrote: > Trivial comment and exception text update, correcting a bug ID to make more sense. Thanks Chris, thanks Daniel! ------------- PR: https://git.openjdk.java.net/jdk/pull/7371 From kevinw at openjdk.java.net Mon Feb 7 18:19:10 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 18:19:10 GMT Subject: Integrated: 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 17:28:29 GMT, Kevin Walls wrote: > Trivial comment and exception text update, correcting a bug ID to make more sense. This pull request has now been integrated. Changeset: 8a662105 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/8a662105c2da1f0fb9b7ecc5058fc85858439ed9 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 6779701: Wrong defect ID in the code of test LocalRMIServerSocketFactoryTest.java Reviewed-by: cjplummer, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7371 From kevinw at openjdk.java.net Mon Feb 7 18:53:08 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 7 Feb 2022 18:53:08 GMT Subject: RFR: 8281377: Remove vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java from problemlist. In-Reply-To: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> References: <0fc1mZX9XJv2W1qwwSPT1aQTnz1fVYlEDh-gjYgRmho=.828f31f4-4f20-495d-923f-b58b6dfde5f7@github.com> Message-ID: On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote: > Test failed many years ago. > Cannot provoke a failure today in hundreds of runs. > Initial failure may have been specific to Solaris. Right - vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/MixedDeadlock001/TestDescription.java does not appear to fail recently except that one old mention, or the other scenarios tested. ------------- PR: https://git.openjdk.java.net/jdk/pull/7369 From amenkov at openjdk.java.net Tue Feb 8 16:55:42 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 8 Feb 2022 16:55:42 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times Message-ID: ClassLoaderDataGraph::classes_do description says: // Walking classes through the ClassLoaderDataGraph include array classes. So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) ------------- Commit messages: - JDK-8281267 Changes: https://git.openjdk.java.net/jdk/pull/7384/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281267 Stats: 361 lines in 2 files changed: 338 ins; 10 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384 PR: https://git.openjdk.java.net/jdk/pull/7384 From duke at openjdk.java.net Wed Feb 9 15:44:58 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 15:44:58 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v5] In-Reply-To: References: Message-ID: > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: Revert "removed file with declarations that are never defined or used: /src/hotspot/share/services/dtraceAttacher.hpp" This reverts commit 885b985bb3618fc621cac1a32159b5449b5026fb. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7110/files - new: https://git.openjdk.java.net/jdk/pull/7110/files/0f161b01..7a93ecae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=03-04 Stats: 55 lines in 5 files changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7110/head:pull/7110 PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 15:44:59 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 15:44:59 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 01:10:34 GMT, David Holmes wrote: >> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'JDK-8278423' of https://github.com/eme64/jdk into JDK-8278423 >> - added flag to VMDeprecatedOptions Test > > src/hotspot/os/aix/attachListener_aix.cpp line 31: > >> 29: #include "runtime/os.inline.hpp" >> 30: #include "services/attachListener.hpp" >> 31: > > These changes are somewhat independent of the deprecation issue and could be split out into a separate RFE. The serviceability folk may have an opinion. @dholmes-ora Ok, I reverted this and will do it in a separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 15:54:47 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 15:54:47 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v6] In-Reply-To: References: Message-ID: <1aigQ1zndvru8IqC1RgnZ8mGZecF4kaxUi2039maPPQ=.59745cd8-5be3-4b2a-8976-42ac25404987@github.com> > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: replaced with 3 flags in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7110/files - new: https://git.openjdk.java.net/jdk/pull/7110/files/7a93ecae..be3e0b81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=04-05 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7110/head:pull/7110 PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 15:54:50 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 15:54:50 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v4] In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 18:42:27 GMT, Harold Seigel wrote: > Can you replace the use of -XX:+ExtendedDTraceProbes in test/hotspot/jtreg/serviceability/7170638/SDTProbesGNULinuxTest.java with the three new flags ? Thank you @hseigel , I patched it according to your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 16:10:10 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 16:10:10 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 01:12:16 GMT, David Holmes wrote: >> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: >> >> moved deprecated flag to deprecated section in manpages > > src/hotspot/share/runtime/arguments.cpp line 2884: > >> 2882: #if defined(DTRACE_ENABLED) >> 2883: warning("Option ExtendedDTraceProbes was deprecated in version 19 and will likely be removed in a future release."); >> 2884: warning("Use a combination of -XX:+DTraceMethodProbes, -XX:+DTraceAllocProbes and -XX:+DTraceMonitorProbes instead."); > > s/a/the/ > > Applies to all three uses. Agreed, changing it ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 16:20:49 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 16:20:49 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v7] In-Reply-To: References: Message-ID: > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly. > Added flag to VMDeprecatedOptions test. > > Checked that tests are not affected. Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: updated warning messages and added 3 flags to man-pages ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7110/files - new: https://git.openjdk.java.net/jdk/pull/7110/files/be3e0b81..b05ecfa2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=05-06 Stats: 18 lines in 2 files changed: 16 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7110/head:pull/7110 PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Wed Feb 9 16:20:51 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Wed, 9 Feb 2022 16:20:51 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v4] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 01:17:21 GMT, David Holmes wrote: >> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: >> >> moved deprecated flag to deprecated section in manpages > > src/java.base/share/man/java.1 line 4001: > >> 3999: .TP >> 4000: .B \f[CB]\-XX:+ExtendedDTraceProbes\f[R] >> 4001: Deprecated. Use combination of these flags instead: -XX:+DTraceMethodProbes, -XX:+DTraceAllocProbes, -XX:+DTraceMonitorProbes > > Delete "Deprecated" as we are in the deprecated options section. > > The wording also needs updating as per the warning text ... though that might read a little odd here so I suggest a tweak: > > Use the combination of -XX:+DTraceMethodProbes, -XX:+DTraceAllocProbes and -XX:+DTraceMonitorProbes instead of this deprecated flag. > > > I would also move that new text to the end, so we still describe the flag first (otherwise it again reads a little odd.) > > We will also need to add those flags to the "ADVANCED SERVICEABILITY OPTIONS FOR JAVA" section. @dholmes-ora thanks for the suggestions, I implemented them. ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From hseigel at openjdk.java.net Wed Feb 9 18:51:10 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 9 Feb 2022 18:51:10 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v7] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:20:49 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > updated warning messages and added 3 flags to man-pages Other than the need to update the copyright dates to 2022, these changes look good. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7110 From cjplummer at openjdk.java.net Wed Feb 9 19:49:05 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 9 Feb 2022 19:49:05 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov wrote: > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 58: > 56: String[][][] strArray = new String[0][][]; > 57: LingeredApp.main(args); > 58: System.out.println("" + intArray + strArray); // to be sure the classes are not unloaded Use Reference.reachabilityFence(); test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 86: > 84: Process p = ProcessTools.startProcess("jcmd", new ProcessBuilder(launcher.getCommand())); > 85: // If something goes wrong with heap dumping most likely we'll get crash of the target VM. > 86: while (!p.waitFor(5, TimeUnit.SECONDS)) { 5 seconds seems kind of short. Doesn't allow for occasional network hiccups. test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 218: > 216: } > 217: > 218: // Reads the whole HPROF_GC_CLASS_DUMP record, returns closs ID. "class ID" ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From cjplummer at openjdk.java.net Wed Feb 9 20:20:10 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 9 Feb 2022 20:20:10 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov wrote: > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) src/hotspot/share/services/heapDumper.cpp line 2293: > 2291: // Writes HPROF_GC_CLASS_DUMP records > 2292: // For array classes we need signers and protection domain from their bottom classes > 2293: // so do_class_dump skips array classes and dumps array classes with corresponding instance class. I'm having trouble parsing this comment. Can you clarify? ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From dholmes at openjdk.java.net Thu Feb 10 06:22:15 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 06:22:15 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v7] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:20:49 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > updated warning messages and added 3 flags to man-pages Hi Emanuel, A few minor nits below. Thanks, David src/hotspot/share/runtime/globals.hpp line 1868: > 1866: product(bool, ExtendedDTraceProbes, false, \ > 1867: "(Deprecated) Enable performance-impacting dtrace probes. " \ > 1868: "Use a combination of -XX:+DTraceMethodProbes, " \ You missed changing 'a' to 'the' here. src/java.base/share/man/java.1 line 2977: > 2975: .RE > 2976: .TP > 2977: .B \f[CB]\-XX:+DTraceAllocProbes\f[R] The three newly documented flags should all be marked "Linux and macOS". It is somewhat of a poor design that the flags are available on all platforms but only have an effect on systems with DTrace or SystemTap support - which (for our main platforms) is Linux and macOS. src/java.base/share/man/java.1 line 4017: > 4015: .B \f[CB]\-XX:+ExtendedDTraceProbes\f[R] > 4016: \f[B]Linux and macOS:\f[R] Enables additional \f[CB]dtrace\f[R] tool probes > 4017: that affect the performance. Existing grammatical nit: please delete 'the'. src/java.base/share/man/java.1 line 4020: > 4018: By default, this option is disabled and \f[CB]dtrace\f[R] performs only > 4019: standard probes. > 4020: Use the combination of these flags instead: -XX:+DTraceMethodProbes, -XX:+DTraceAllocProbes, -XX:+DTraceMonitorProbes The flags should be in a code font (use `-XX:...` in the markdown source). ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Thu Feb 10 08:46:50 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Thu, 10 Feb 2022 08:46:50 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v8] In-Reply-To: References: Message-ID: <6_ddanyI-FFaerYCGBHYYGlJQZpUvypaIIoPOq6S3wM=.b77c72f2-e29a-4d31-826c-f42c737978d1@github.com> > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly, added the 3 flags to man pages. > Added flag to VMDeprecatedOptions test. > Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. > > Checked that tests are not affected. Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: fixes to documentation requested by reviewers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7110/files - new: https://git.openjdk.java.net/jdk/pull/7110/files/b05ecfa2..af11b456 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=06-07 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7110/head:pull/7110 PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Thu Feb 10 08:46:55 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Thu, 10 Feb 2022 08:46:55 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v7] In-Reply-To: References: Message-ID: <2wP_TEQJtQvj6ALRgl4BG_QnXkLVqBntoZleXWDIDaU=.ccd0ae17-7ed8-4ec5-955b-476941ab37b9@github.com> On Thu, 10 Feb 2022 05:54:17 GMT, David Holmes wrote: >> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: >> >> updated warning messages and added 3 flags to man-pages > > src/hotspot/share/runtime/globals.hpp line 1868: > >> 1866: product(bool, ExtendedDTraceProbes, false, \ >> 1867: "(Deprecated) Enable performance-impacting dtrace probes. " \ >> 1868: "Use a combination of -XX:+DTraceMethodProbes, " \ > > You missed changing 'a' to 'the' here. done > src/java.base/share/man/java.1 line 2977: > >> 2975: .RE >> 2976: .TP >> 2977: .B \f[CB]\-XX:+DTraceAllocProbes\f[R] > > The three newly documented flags should all be marked "Linux and macOS". It is somewhat of a poor design that the flags are available on all platforms but only have an effect on systems with DTrace or SystemTap support - which (for our main platforms) is Linux and macOS. done > src/java.base/share/man/java.1 line 4017: > >> 4015: .B \f[CB]\-XX:+ExtendedDTraceProbes\f[R] >> 4016: \f[B]Linux and macOS:\f[R] Enables additional \f[CB]dtrace\f[R] tool probes >> 4017: that affect the performance. > > Existing grammatical nit: please delete 'the'. done > src/java.base/share/man/java.1 line 4020: > >> 4018: By default, this option is disabled and \f[CB]dtrace\f[R] performs only >> 4019: standard probes. >> 4020: Use the combination of these flags instead: -XX:+DTraceMethodProbes, -XX:+DTraceAllocProbes, -XX:+DTraceMonitorProbes > > The flags should be in a code font (use `-XX:...` in the markdown source). done ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From dholmes at openjdk.java.net Thu Feb 10 10:50:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 10:50:11 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v8] In-Reply-To: <6_ddanyI-FFaerYCGBHYYGlJQZpUvypaIIoPOq6S3wM=.b77c72f2-e29a-4d31-826c-f42c737978d1@github.com> References: <6_ddanyI-FFaerYCGBHYYGlJQZpUvypaIIoPOq6S3wM=.b77c72f2-e29a-4d31-826c-f42c737978d1@github.com> Message-ID: On Thu, 10 Feb 2022 08:46:50 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > fixes to documentation requested by reviewers Thanks for the updates. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7110 From amenkov at openjdk.java.net Thu Feb 10 12:00:09 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 10 Feb 2022 12:00:09 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 20:17:22 GMT, Chris Plummer wrote: >> ClassLoaderDataGraph::classes_do description says: >> // Walking classes through the ClassLoaderDataGraph include array classes. >> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) > > src/hotspot/share/services/heapDumper.cpp line 2293: > >> 2291: // Writes HPROF_GC_CLASS_DUMP records >> 2292: // For array classes we need signers and protection domain from their bottom classes >> 2293: // so do_class_dump skips array classes and dumps array classes with corresponding instance class. > > I'm having trouble parsing this comment. Can you clarify? HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects. But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types). do_class_dump callback skips array classes: if (k->is_instance_klass()) { DumperSupport::dump_class_and_array_classes(writer(), k); } dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified). This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately. I added the comment to explain why do_class_dump goes this tricky way. Do you have any suggestions how to rephrase it to make clearer? ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Thu Feb 10 12:48:41 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 10 Feb 2022 12:48:41 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2] In-Reply-To: References: Message-ID: > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7384/files - new: https://git.openjdk.java.net/jdk/pull/7384/files/c227bd68..604b4f88 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384 PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Thu Feb 10 12:48:45 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 10 Feb 2022 12:48:45 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:38:43 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated test > > test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 58: > >> 56: String[][][] strArray = new String[0][][]; >> 57: LingeredApp.main(args); >> 58: System.out.println("" + intArray + strArray); // to be sure the classes are not unloaded > > Use Reference.reachabilityFence(); Fixed > test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 86: > >> 84: Process p = ProcessTools.startProcess("jcmd", new ProcessBuilder(launcher.getCommand())); >> 85: // If something goes wrong with heap dumping most likely we'll get crash of the target VM. >> 86: while (!p.waitFor(5, TimeUnit.SECONDS)) { > > 5 seconds seems kind of short. Doesn't allow for occasional network hiccups. Note that this is a cycle. It ensures target VM (theApp) is not terminated while jcmd (p) processes the command. I had some experience in the past when jcmd didn't exit if target VM crashes. > test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 218: > >> 216: } >> 217: >> 218: // Reads the whole HPROF_GC_CLASS_DUMP record, returns closs ID. > > "class ID" Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From lkorinth at openjdk.java.net Thu Feb 10 15:47:23 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Thu, 10 Feb 2022 15:47:23 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc Message-ID: Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. ------------- Commit messages: - 8281585: Remove unused imports under test/lib and jtreg/gc Changes: https://git.openjdk.java.net/jdk/pull/7426/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281585 Stats: 92 lines in 60 files changed: 0 ins; 92 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426 PR: https://git.openjdk.java.net/jdk/pull/7426 From dholmes at openjdk.java.net Thu Feb 10 23:24:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 23:24:11 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Looks fine. The proof of these changes is in compiling the files - how did you test the non-gc-test changes? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From dholmes at openjdk.java.net Thu Feb 10 23:33:09 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 23:33:09 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Forgot to mention copyright years need updating before integrating! Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From yyang at openjdk.java.net Fri Feb 11 03:35:10 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 11 Feb 2022 03:35:10 GMT Subject: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v2] In-Reply-To: References: <_Pw-D6A2BD-4wx0mZ5lFvFlxBRylbA5WT9y5xgtDBvk=.fa85a604-e6a0-463b-8a4a-4ae7e210661a@github.com> Message-ID: On Tue, 18 Jan 2022 02:59:11 GMT, David Holmes wrote: >> Yi Yang 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: >> >> 8275775 Add VM.classes to print details of all classes > > src/hotspot/share/oops/instanceKlass.cpp line 2069: > >> 2067: ResourceMark rm; >> 2068: _st->print("%-18s", "KlassAddr"); >> 2069: _st->print(" "); > > Can't you just print the two spaces in the previous line: > > _st->print("%-18s ", "KlassAddr"); > > and save all the additional print calls. This applies throughout where you have " ". @dholmes-ora David, Can you please take a look at the latest version? I've addressed all problems you pointed out. ------------- PR: https://git.openjdk.java.net/jdk/pull/7105 From kvn at openjdk.java.net Fri Feb 11 04:17:10 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Feb 2022 04:17:10 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v8] In-Reply-To: <6_ddanyI-FFaerYCGBHYYGlJQZpUvypaIIoPOq6S3wM=.b77c72f2-e29a-4d31-826c-f42c737978d1@github.com> References: <6_ddanyI-FFaerYCGBHYYGlJQZpUvypaIIoPOq6S3wM=.b77c72f2-e29a-4d31-826c-f42c737978d1@github.com> Message-ID: On Thu, 10 Feb 2022 08:46:50 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > fixes to documentation requested by reviewers Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7110 From dholmes at openjdk.java.net Fri Feb 11 07:01:10 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Feb 2022 07:01:10 GMT Subject: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v6] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 09:17:09 GMT, Yi Yang wrote: >> Add VM.classes to print details of all classes, output looks like: >> >> 1. jcmd VM.classes >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x0000000800c0b400 62 inited W bootstrap java.lang.invoke.LambdaForm$MH/0x0000000800c0b400 >> 0x0000000800c0b000 62 inited W bootstrap java.lang.invoke.LambdaForm$DMH/0x0000000800c0b000 >> 0x0000000800c0ac00 62 inited W bootstrap java.lang.invoke.LambdaForm$MH/0x0000000800c0ac00 >> ... >> >> 2. jcmd VM.classes verbose >> >> KlassAddr Size State Flags LoaderName ClassName >> 0x0000000800c0b400 62 inited W bootstrap java.lang.invoke.LambdaForm$MH/0x0000000800c0b400 >> java.lang.invoke.LambdaForm$MH/0x0000000800c0b400 {0x0000000800c0b400} >> - instance size: 2 >> - klass size: 62 >> - access: final synchronized >> - state: inited >> - name: 'java/lang/invoke/LambdaForm$MH+0x0000000800c0b400' >> - super: 'java/lang/Object' >> - sub: >> - arrays: NULL >> - methods: Array(0x00007f620841f210) >> - method ordering: Array(0x0000000800a7e5a8) >> - default_methods: Array(0x0000000000000000) >> - local interfaces: Array(0x00000008005af748) >> - trans. interfaces: Array(0x00000008005af748) >> - constants: constant pool [41] {0x00007f620841f030} for 'java/lang/invoke/LambdaForm$MH+0x0000000800c0b400' cache=0x00007f620841f380 >> - class loader data: loader data: 0x00007f61c804a690 of 'bootstrap' has a class holder >> - source file: 'LambdaForm$MH' >> - class annotations: Array(0x0000000000000000) >> - class type annotations: Array(0x0000000000000000) >> - field annotations: Array(0x0000000000000000) >> - field type annotations: Array(0x0000000000000000) >> - inner classes: Array(0x00000008005af6d8) >> - nest members: Array(0x00000008005af6d8) >> - permitted subclasses: Array(0x00000008005af6d8) >> - java mirror: a 'java/lang/Class'{0x000000011f4b3968} = 'java/lang/invoke/LambdaForm$MH+0x0000000800c0b400' >> - vtable length 5 (start addr: 0x0000000800c0b5b8) >> - itable length 2 (start addr: 0x0000000800c0b5e0) >> - ---- static fields (1 words): >> - static final '_D_0' 'Ljava/lang/invoke/LambdaForm;' @112 >> - ---- non-static fields (0 words): >> - non-static oop maps: >> 0x0000000800c0b000 62 inited W bootstrap java.lang.invoke.LambdaForm$DMH/0x0000000800c0b000 >> java.lang.invoke.LambdaForm$DMH/0x0000000800c0b000 {0x0000000800c0b000} >> - instance size: 2 >> - klass size: 62 >> - access: final synchronized >> - state: inited >> - name: 'java/lang/invoke/LambdaForm$DMH+0x0000000800c0b000' >> - super: 'java/lang/Object' >> - sub: >> - arrays: NULL >> - methods: Array(0x00007f620841ea68) >> - method ordering: Array(0x0000000800a7e5a8) >> - default_methods: Array(0x0000000000000000) >> - local interfaces: Array(0x00000008005af748) >> - trans. interfaces: Array(0x00000008005af748) >> - constants: constant pool [49] {0x00007f620841e838} for 'java/lang/invoke/LambdaForm$DMH+0x0000000800c0b000' cache=0x00007f620841ebe0 >> - class loader data: loader data: 0x00007f61c804a750 of 'bootstrap' has a class holder >> - source file: 'LambdaForm$DMH' >> - class annotations: Array(0x0000000000000000) >> - class type annotations: Array(0x0000000000000000) >> - field annotations: Array(0x0000000000000000) >> - field type annotations: Array(0x0000000000000000) >> - inner classes: Array(0x00000008005af6d8) >> - nest members: Array(0x00000008005af6d8) >> - permitted subclasses: Array(0x00000008005af6d8) >> - java mirror: a 'java/lang/Class'{0x000000011f4b0968} = 'java/lang/invoke/LambdaForm$DMH+0x0000000800c0b000' >> - vtable length 5 (start addr: 0x0000000800c0b1b8) >> - itable length 2 (start addr: 0x0000000800c0b1e0) >> - ---- static fields (1 words): >> - static final '_D_0' 'Ljava/lang/invoke/LambdaForm;' @112 >> - ---- non-static fields (0 words): >> ... > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > fix Hi Yi, I had been expecting to see further updates as not all issues seem resolved. I have a few further typos and nits below. But I'd like to see someone from serviceability actually approve this. Thanks, David src/hotspot/share/services/diagnosticCommand.cpp line 962: > 960: DCmdWithParser(output, heap), > 961: _verbose("-verbose", > 962: "Dump the detail content of Java class. " s/detail/detailed/ s/of/of a/ src/hotspot/share/services/diagnosticCommand.cpp line 964: > 962: "Dump the detail content of Java class. " > 963: "Some classes are annotated with flags: " > 964: "F = has finializer method, " typo finializer - but should be finalize Is this actually only present for "non-trivial finalize" method? src/hotspot/share/services/diagnosticCommand.cpp line 966: > 964: "F = has finializer method, " > 965: "f = has final method, " > 966: "V = has vanilla constructor, " What is a vanilla constructor? There is no such term in JLS. src/hotspot/share/services/diagnosticCommand.cpp line 968: > 966: "V = has vanilla constructor, " > 967: "W = methods rewritten, " > 968: "C = marked with contended annotation, " @contended ------------- PR: https://git.openjdk.java.net/jdk/pull/7105 From dholmes at openjdk.java.net Fri Feb 11 07:01:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Feb 2022 07:01:11 GMT Subject: RFR: 8275775: Add jcmd VM.classes to print details of all classes [v6] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 16:00:54 GMT, Ioi Lam wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix > > src/hotspot/share/oops/instanceKlass.cpp line 2081: > >> 2079: _st->print(INTPTR_FORMAT " ", p2i(k)); >> 2080: // klass size >> 2081: _st->print("%-4d ", k->size()); > > Should be `%4d` so that the numbers are aligned correctly. This issue seem still outstanding. ------------- PR: https://git.openjdk.java.net/jdk/pull/7105 From duke at openjdk.java.net Fri Feb 11 08:52:48 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Fri, 11 Feb 2022 08:52:48 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v9] In-Reply-To: References: Message-ID: > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly, added the 3 flags to man pages. > Added flag to VMDeprecatedOptions test. > Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. > > Checked that tests are not affected. Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: fix in response to suggestion by David Holmes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7110/files - new: https://git.openjdk.java.net/jdk/pull/7110/files/af11b456..78d8e00a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7110&range=07-08 Stats: 9 lines in 2 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7110/head:pull/7110 PR: https://git.openjdk.java.net/jdk/pull/7110 From lkorinth at openjdk.java.net Fri Feb 11 08:54:51 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 11 Feb 2022 08:54:51 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: updating copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7426/files - new: https://git.openjdk.java.net/jdk/pull/7426/files/6aaa1a3a..7d3e7a1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00-01 Stats: 59 lines in 59 files changed: 0 ins; 0 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/7426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426 PR: https://git.openjdk.java.net/jdk/pull/7426 From lkorinth at openjdk.java.net Fri Feb 11 09:01:06 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 11 Feb 2022 09:01:06 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright I have a maven project that compiles test/lib and jtreg/gc, so everything changed does compile, I should have mentioned that. I have updated copyright year on all files now as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From sspitsyn at openjdk.java.net Fri Feb 11 10:14:09 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 11 Feb 2022 10:14:09 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From thartmann at openjdk.java.net Fri Feb 11 10:24:10 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 11 Feb 2022 10:24:10 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v9] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:52:48 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > fix in response to suggestion by David Holmes Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7110 From dholmes at openjdk.java.net Fri Feb 11 12:50:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Feb 2022 12:50:07 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v9] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:52:48 GMT, Emanuel Peter wrote: >> Deprecated ExtendedDTraceProbes. >> Edited help messages and man pages accordingly, added the 3 flags to man pages. >> Added flag to VMDeprecatedOptions test. >> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. >> >> Checked that tests are not affected. > > Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: > > fix in response to suggestion by David Holmes Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From dholmes at openjdk.java.net Fri Feb 11 13:01:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Feb 2022 13:01:04 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From duke at openjdk.java.net Fri Feb 11 21:07:14 2022 From: duke at openjdk.java.net (duke) Date: Fri, 11 Feb 2022 21:07:14 GMT Subject: Withdrawn: 8274982: Add a test for 8269574. In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote: > This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5889 From duke at openjdk.java.net Sat Feb 12 09:38:09 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Sat, 12 Feb 2022 09:38:09 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v9] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 12:46:51 GMT, David Holmes wrote: >> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision: >> >> fix in response to suggestion by David Holmes > > Marked as reviewed by dholmes (Reviewer). Thanks @dholmes-ora , @vnkozlov , @TobiHartmann @hseigel for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From duke at openjdk.java.net Sat Feb 12 13:12:06 2022 From: duke at openjdk.java.net (Emanuel Peter) Date: Sat, 12 Feb 2022 13:12:06 GMT Subject: Integrated: 8278423: ExtendedDTraceProbes should be deprecated In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 13:08:17 GMT, Emanuel Peter wrote: > Deprecated ExtendedDTraceProbes. > Edited help messages and man pages accordingly, added the 3 flags to man pages. > Added flag to VMDeprecatedOptions test. > Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java. > > Checked that tests are not affected. This pull request has now been integrated. Changeset: 67077a04 Author: Emanuel Peter Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/67077a04307b512219a46b6c4c274ce308ee46de Stats: 36 lines in 5 files changed: 26 ins; 0 del; 10 mod 8278423: ExtendedDTraceProbes should be deprecated Reviewed-by: dholmes, hseigel, kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From dholmes at openjdk.java.net Sat Feb 12 13:53:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 12 Feb 2022 13:53:07 GMT Subject: RFR: 8278423: ExtendedDTraceProbes should be deprecated [v9] In-Reply-To: References: Message-ID: <1F1lA8O1LUcjG7jN9zKWggndsrjftGjyY9SNkGi0IQ0=.6980ebbb-58f5-4a08-97ae-ab4272e47e88@github.com> On Sat, 12 Feb 2022 09:34:28 GMT, Emanuel Peter wrote: >> Marked as reviewed by dholmes (Reviewer). > > Thanks @dholmes-ora , @vnkozlov , @TobiHartmann @hseigel for the reviews. @eme64 the test fails in our CI as it encounters builds for which DTrace is not enabled - see JDK-8281675. ------------- PR: https://git.openjdk.java.net/jdk/pull/7110 From cjplummer at openjdk.java.net Mon Feb 14 05:06:09 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 14 Feb 2022 05:06:09 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:57:25 GMT, Alex Menkov wrote: >> src/hotspot/share/services/heapDumper.cpp line 2293: >> >>> 2291: // Writes HPROF_GC_CLASS_DUMP records >>> 2292: // For array classes we need signers and protection domain from their bottom classes >>> 2293: // so do_class_dump skips array classes and dumps array classes with corresponding instance class. >> >> I'm having trouble parsing this comment. Can you clarify? > > HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects. > But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types). > do_class_dump callback skips array classes: > if (k->is_instance_klass()) { > DumperSupport::dump_class_and_array_classes(writer(), k); > } > > dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified). > > This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately. > > I added the comment to explain why do_class_dump goes this tricky way. > Do you have any suggestions how to rephrase it to make clearer? Sorry about the delay. I didn't see your response when it came in. It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array? ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Mon Feb 14 09:22:17 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 14 Feb 2022 09:22:17 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:02:34 GMT, Chris Plummer wrote: >> HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects. >> But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types). >> do_class_dump callback skips array classes: >> if (k->is_instance_klass()) { >> DumperSupport::dump_class_and_array_classes(writer(), k); >> } >> >> dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified). >> >> This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately. >> >> I added the comment to explain why do_class_dump goes this tricky way. >> Do you have any suggestions how to rephrase it to make clearer? > > Sorry about the delay. I didn't see your response when it came in. > > It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array? This comment explains why we call ClassLoaderDataGraph::classes_do(do_class_dump) and then Universe::basic_type_classes_do(&do_basic_type_array_class_dump). Bottom klass is 1-dimensional type. For example for [[LObject; element type is [lObject;, and bottom klass is LObject; Looked at the code and see that ObjAyyaKlass actually contains link to it - see ObjArrayKlass::bottom_klass(), so I can update do_class_dump to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From lkorinth at openjdk.java.net Mon Feb 14 12:08:13 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 14 Feb 2022 12:08:13 GMT Subject: Integrated: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. This pull request has now been integrated. Changeset: 2604a88f Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c Stats: 151 lines in 60 files changed: 0 ins; 92 del; 59 mod 8281585: Remove unused imports under test/lib and jtreg/gc Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From lkorinth at openjdk.java.net Mon Feb 14 12:08:12 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 14 Feb 2022 12:08:12 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Thanks David and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From amenkov at openjdk.java.net Mon Feb 14 13:05:52 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 14 Feb 2022 13:05:52 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: References: Message-ID: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: reworked do_class_dump ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7384/files - new: https://git.openjdk.java.net/jdk/pull/7384/files/604b4f88..173a8da8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=01-02 Stats: 96 lines in 1 file changed: 11 ins; 58 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/7384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384 PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Mon Feb 14 13:11:10 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 14 Feb 2022 13:11:10 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 09:18:34 GMT, Alex Menkov wrote: >> Sorry about the delay. I didn't see your response when it came in. >> >> It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array? > > This comment explains why we call ClassLoaderDataGraph::classes_do(do_class_dump) and then Universe::basic_type_classes_do(&do_basic_type_array_class_dump). > > Bottom klass is 1-dimensional type. > For example for [[LObject; element type is [lObject;, and bottom klass is LObject; > Looked at the code and see that ObjArrayKlass actually contains link to it - see ObjArrayKlass::bottom_klass(), so I can update do_class_dump to use it. I updated the fix, fixed do_class_dump and removed this comment. This also removes code duplication in dump_class_and_array_classes and dump_basic_type_array_class ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From zgu at openjdk.java.net Mon Feb 14 14:34:37 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 14 Feb 2022 14:34:37 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent Message-ID: There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. **Java Thread** - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) **VM Thread** - post `JVMTI_EVENT_OBJECT_FREE` - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. Test: - [x] tier1 - [x] vmTestbase_nsk_jdi - [x] vmTestbase_nsk_jdwp - [x] vmTestbase_nsk_jvmti ------------- Commit messages: - Update comments - v0 Changes: https://git.openjdk.java.net/jdk/pull/7461/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281615 Stats: 25 lines in 1 file changed: 21 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461 From dholmes at openjdk.java.net Mon Feb 14 23:33:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Feb 2022 23:33:12 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent In-Reply-To: References: Message-ID: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> On Mon, 14 Feb 2022 14:27:45 GMT, Zhengyu Gu wrote: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Hi Zhengyu, I don't think the fix is correct - see below. Thanks, David src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 100: > 98: struct bag* deleted = deletedSignatures; > 99: deletedSignatures = NULL; > 100: debugMonitorExit(classTrackLock); This looks risky as the critical section is broken and the NULL deleted signatures exposed. If `cbTrackingObjectFree` occurs while this is true then you will lose the record of the deleted signature. Alternatively you could allow for lock-free reading of `deletedSignatures`, preemptively allocate a new bad if needed then take the lock. Or even use the lock to read `deletedSignatures` to determine if a new bag is needed, then drop the lock, create the bag, take the lock and re-check everything. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 215: > 213: classTrack_activate(JNIEnv *env) > 214: { > 215: struct bag* new_bag = bagCreateBag(sizeof(char*), 1000); I don't think there can be any race during activation but this change is harmless. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 240: > 238: if (deletedSignatures != NULL) { > 239: bagEnumerateOver(deletedSignatures, cleanDeleted, NULL); > 240: to_delete = deletedSignatures; `cleanDeleted` also calls `jvmtiDeallocate`, so either both need to be outside the lock or neither. It is really unclear to me how many threads can be involved here and which functions can be called when. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 15 06:14:12 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 06:14:12 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> Message-ID: On Mon, 14 Feb 2022 13:05:52 GMT, Alex Menkov wrote: >> ClassLoaderDataGraph::classes_do description says: >> // Walking classes through the ClassLoaderDataGraph include array classes. >> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > reworked do_class_dump The changes look good. Have you verified that after your most recent changes you get the same sized hprof file as with your initial changes? ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7384 From cjplummer at openjdk.java.net Tue Feb 15 06:21:17 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 06:21:17 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 14:27:45 GMT, Zhengyu Gu wrote: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Slight correction to the following in your description: > JDWP event callback handler calls classTrack_processUnloads() to handle the event. classTrack_processUnloads() isn't called to handle the event. It's called as a side affect of handling the event. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 15 06:43:19 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 06:43:19 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent In-Reply-To: References: Message-ID: <0a0TftMYFh67WBTzk6RtCb7Pnb1tXBDtzibrS_2yGF4=.3b606dad-567f-4079-8862-03b9d6fb322e@github.com> On Mon, 14 Feb 2022 14:27:45 GMT, Zhengyu Gu wrote: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 65: > 63: * handler may acquire the same monitor(s), e.g. classTrackLock in cbTrackingObjectFree(), > 64: * which can lead to deadlock. > 65: */ The debug agent does a lot alloc/dealloc calls while processing JVMTI events and holding locks. So the question is why this is not problematic other than this classTrackLock issue. I believe the answer is that cbTrackingObjectFree() is unique in that it is handled outside of the debug agent's normal event handling code, which is serialized. cbTrackingObjectFree() is called so the debug agent can maintain a list of loaded classes, and is not an event that gets passed on to the debugger like most JVMTI events are. So we have a case here where classTrackLock can be grabbed by both "typical" JVMTI event handling code via the classTrack_processUnloads() call, and then this special cbTrackingObjectFree() event handling. I think having this comment here doesn't help the reader of the code below unless they somehow read the comment first and then recognized it's application in the code below. At the very least the code below should tersely state while the lock is being released, and then refer to this comment for details. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 15 06:43:20 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 06:43:20 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent In-Reply-To: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> Message-ID: On Mon, 14 Feb 2022 23:11:34 GMT, David Holmes wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 100: > >> 98: struct bag* deleted = deletedSignatures; >> 99: deletedSignatures = NULL; >> 100: debugMonitorExit(classTrackLock); > > This looks risky as the critical section is broken and the NULL deleted signatures exposed. If `cbTrackingObjectFree` occurs while this is true then you will lose the record of the deleted signature. > > Alternatively you could allow for lock-free reading of `deletedSignatures`, preemptively allocate a new bad if needed then take the lock. Or even use the lock to read `deletedSignatures` to determine if a new bag is needed, then drop the lock, create the bag, take the lock and re-check everything. Agreed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From amenkov at openjdk.java.net Tue Feb 15 11:59:06 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 15 Feb 2022 11:59:06 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> Message-ID: On Tue, 15 Feb 2022 06:10:57 GMT, Chris Plummer wrote: > The changes look good. Have you verified that after your most recent changes you get the same sized hprof file as with your initial changes? Thank you for the review. I verified number of classes (HPROF_LOAD_CLASS and HPROF_GC_CLASS_DUMP records) are the same with initial change and with the most recent (and the numbers of HPROF_GC_CLASS_DUMP records are the same as without the fix). Size of the hprof file changes slightly from run to run (+-1KB for 2.5MB hprof file), so we can't rely on it ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From zgu at openjdk.java.net Tue Feb 15 17:48:43 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 17:48:43 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: David and Chris' comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7461/files - new: https://git.openjdk.java.net/jdk/pull/7461/files/45b45b89..d72294c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=00-01 Stats: 45 lines in 1 file changed: 17 ins; 9 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Tue Feb 15 17:48:44 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 17:48:44 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> Message-ID: <33R1h7fu21nHgp6fwZB1HrcDd0a1e98yljztlqvp5Yc=.6a0342bd-2bb5-45ad-be18-bd0dc5a460ac@github.com> On Tue, 15 Feb 2022 06:36:36 GMT, Chris Plummer wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 100: >> >>> 98: struct bag* deleted = deletedSignatures; >>> 99: deletedSignatures = NULL; >>> 100: debugMonitorExit(classTrackLock); >> >> This looks risky as the critical section is broken and the NULL deleted signatures exposed. If `cbTrackingObjectFree` occurs while this is true then you will lose the record of the deleted signature. >> >> Alternatively you could allow for lock-free reading of `deletedSignatures`, preemptively allocate a new bad if needed then take the lock. Or even use the lock to read `deletedSignatures` to determine if a new bag is needed, then drop the lock, create the bag, take the lock and re-check everything. > > Agreed. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Tue Feb 15 17:56:12 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 17:56:12 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> Message-ID: <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> On Mon, 14 Feb 2022 23:26:17 GMT, David Holmes wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> David and Chris' comments > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 215: > >> 213: classTrack_activate(JNIEnv *env) >> 214: { >> 215: struct bag* new_bag = bagCreateBag(sizeof(char*), 1000); > > I don't think there can be any race during activation but this change is harmless. I am not sure classTrack_activate() has the problem, but it is called outside of initialization, inside debug loop ... so I assume that event callback might happen. > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 240: > >> 238: if (deletedSignatures != NULL) { >> 239: bagEnumerateOver(deletedSignatures, cleanDeleted, NULL); >> 240: to_delete = deletedSignatures; > > `cleanDeleted` also calls `jvmtiDeallocate`, so either both need to be outside the lock or neither. > > It is really unclear to me how many threads can be involved here and which functions can be called when. Right. Moved `bagEnumerateOver()` outside of lock as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Tue Feb 15 17:56:12 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 17:56:12 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: <0a0TftMYFh67WBTzk6RtCb7Pnb1tXBDtzibrS_2yGF4=.3b606dad-567f-4079-8862-03b9d6fb322e@github.com> References: <0a0TftMYFh67WBTzk6RtCb7Pnb1tXBDtzibrS_2yGF4=.3b606dad-567f-4079-8862-03b9d6fb322e@github.com> Message-ID: On Tue, 15 Feb 2022 06:31:46 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> David and Chris' comments > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 65: > >> 63: * handler may acquire the same monitor(s), e.g. classTrackLock in cbTrackingObjectFree(), >> 64: * which can lead to deadlock. >> 65: */ > > The debug agent does a lot alloc/dealloc calls while processing JVMTI events and holding locks. So the question is why this is not problematic other than this classTrackLock issue. I believe the answer is that cbTrackingObjectFree() is unique in that it is handled outside of the debug agent's normal event handling code, which is serialized. cbTrackingObjectFree() is called so the debug agent can maintain a list of loaded classes, and is not an event that gets passed on to the debugger like most JVMTI events are. So we have a case here where classTrackLock can be grabbed by both "typical" JVMTI event handling code via the classTrack_processUnloads() call, and then this special cbTrackingObjectFree() event handling. > > I think having this comment here doesn't help the reader of the code below unless they somehow read the comment first and then recognized it's application in the code below. At the very least the code below should tersely state while the lock is being released, and then refer to this comment for details. I moved comments inside `classTrack_processUnloads()`, let me know if you prefer other places. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 15 20:22:11 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 20:22:11 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:48:43 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > David and Chris' comments src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 88: > 86: jboolean retry = JNI_FALSE; > 87: do { > 88: // Avoid unnecessary allocations when class track has yet been activated. I don't think this comment is accurate. It's not that we want to avoid unnecessary allocations. We want to avoid unnecessary tracking of loaded classes. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 89: > 87: do { > 88: // Avoid unnecessary allocations when class track has yet been activated. > 89: if (deletedSignatures != NULL) { It's now kind of hard to read what used to be the `deletedSignatures == NULL` case. I think you can first just check for NULL outside the lock and then return. It will make it clear that it is very low overhead in this case. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 111: > 109: } > 110: debugMonitorExit(classTrackLock); > 111: } while (retry == JNI_TRUE); I don't think the retry is necessary. Nor is the check for `deletedSignatures != NULL`. I assume you are trying to cover the case where initially deletedSignatures was NULL (so no bag was allocated), but is not NULL by the time you grab the lock. If you return when NULL like I suggested above, you won't have this issue. Note that if not NULL, there is no way another thread can get into this same code in clear it. This is because all callers first grab the handlerLock. Grabbing of the classTrackLock here is only done to synchronize with cbTrackingObjectFree(), not with other callers of classTrack_processUnloads(). src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 112: > 110: debugMonitorExit(classTrackLock); > 111: } while (retry == JNI_TRUE); > 112: bagDestroyBag(new_bag); One other comment about `classTrack_processUnloads()` in general that also applies to the original version. It seems pretty inefficient. Every time the debug agent gets an event it is called. On almost ever call it is returning and empty back and allocating a new one. It seems a check for `bagSize(deletedSignatures) == 0` and returning NULL if true would help performance. I also believe this can be done outside of the lock (would like David's opinion on this). ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 15 20:22:12 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 15 Feb 2022 20:22:12 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> Message-ID: <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> On Tue, 15 Feb 2022 17:50:19 GMT, Zhengyu Gu wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 215: >> >>> 213: classTrack_activate(JNIEnv *env) >>> 214: { >>> 215: struct bag* new_bag = bagCreateBag(sizeof(char*), 1000); >> >> I don't think there can be any race during activation but this change is harmless. > > I am not sure classTrack_activate() has the problem, but it is called outside of initialization, inside debug loop ... so I assume that event callback might happen. I agree. This code is called when the debug agent receives a CLASS_UNLOAD EventRequest (which the debug agent handles by requesting JVMTI GC_FINISH events). So there is nothing that prevents `classTrack_processUnloads()` from being called at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From ayang at openjdk.java.net Tue Feb 15 20:28:28 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 15 Feb 2022 20:28:28 GMT Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration Message-ID: Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc. Test: tier1-6 ------------- Commit messages: - flatten-cardgen Changes: https://git.openjdk.java.net/jdk/pull/7482/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7482&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281879 Stats: 893 lines in 14 files changed: 350 ins; 526 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7482/head:pull/7482 PR: https://git.openjdk.java.net/jdk/pull/7482 From zgu at openjdk.java.net Tue Feb 15 23:53:39 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 23:53:39 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v3] In-Reply-To: References: Message-ID: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Chris' comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7461/files - new: https://git.openjdk.java.net/jdk/pull/7461/files/d72294c6..d6896aec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=01-02 Stats: 29 lines in 1 file changed: 0 ins; 12 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Tue Feb 15 23:56:04 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Feb 2022 23:56:04 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 20:02:50 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> David and Chris' comments > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 111: > >> 109: } >> 110: debugMonitorExit(classTrackLock); >> 111: } while (retry == JNI_TRUE); > > I don't think the retry is necessary. Nor is the check for `deletedSignatures != NULL`. I assume you are trying to cover the case where initially deletedSignatures was NULL (so no bag was allocated), but is not NULL by the time you grab the lock. If you return when NULL like I suggested above, you won't have this issue. Note that if not NULL, there is no way another thread can get into this same code in clear it. This is because all callers first grab the handlerLock. Grabbing of the classTrackLock here is only done to synchronize with cbTrackingObjectFree(), not with other callers of classTrack_processUnloads(). I was worried that `classTrack_activate()` races against 'classTrack_processUnloads()` to set `deletedSignatures`, and you are right, it is also protected under ` handlerLock` lock. It simplifies a code a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Wed Feb 16 00:16:48 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 16 Feb 2022 00:16:48 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Simplify classTrack_reset and revert bagSize check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7461/files - new: https://git.openjdk.java.net/jdk/pull/7461/files/d6896aec..f93bf8d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=02-03 Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Wed Feb 16 00:21:10 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 16 Feb 2022 00:21:10 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 20:08:19 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> David and Chris' comments > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 112: > >> 110: debugMonitorExit(classTrackLock); >> 111: } while (retry == JNI_TRUE); >> 112: bagDestroyBag(new_bag); > > One other comment about `classTrack_processUnloads()` in general that also applies to the original version. It seems pretty inefficient. Every time the debug agent gets an event it is called. On almost ever call it is returning and empty back and allocating a new one. It seems a check for `bagSize(deletedSignatures) == 0` and returning NULL if true would help performance. I also believe this can be done outside of the lock (would like David's opinion on this). I am not sure if it is possible, but checking `bagSize(deletedSignatures) == 0` seems to race against `classTrack_reset()` where it does not take `handlerLock` lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Wed Feb 16 00:57:05 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 16 Feb 2022 00:57:05 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:17:46 GMT, Zhengyu Gu wrote: > I am not sure if it is possible, but checking bagSize(deletedSignatures) == 0 seems to race against classTrack_reset() where it does not take handlerLock lock. I had thought of that too, but I think the way `classTrack_reset()` is called, it is likely not possible for there to be a `classTrack_processUnloads()` also coming in because everything is shut down: ``` threadControl_onDisconnect(); standardHandlers_onDisconnect(); /* * Cut off the transport immediately. This has the effect of * cutting off any events that the eventHelper thread might * be trying to send. */ transport_close(); debugMonitorDestroy(cmdQueueLock); /* Reset for a new connection to this VM if it's still alive */ if ( ! gdata->vmDead ) { debugInit_reset(getEnv()); <--- calls classTrack_reset() } ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Wed Feb 16 01:20:05 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 16 Feb 2022 01:20:05 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: References: Message-ID: <3fT-lfdwit6XNPviQxCDIfCOAqUvv5Mn6kOW43QrB_g=.a7c7fa2b-fcf4-45f6-82a6-2b309c05932c@github.com> On Wed, 16 Feb 2022 00:53:27 GMT, Chris Plummer wrote: >> I am not sure if it is possible, but checking `bagSize(deletedSignatures) == 0` seems to race against `classTrack_reset()` where it does not take `handlerLock` lock. > >> I am not sure if it is possible, but checking bagSize(deletedSignatures) == 0 seems to race against classTrack_reset() where it does not take handlerLock lock. > > I had thought of that too, but I think the way `classTrack_reset()` is called, it is likely not possible for there to be a `classTrack_processUnloads()` also coming in because everything is shut down: > > ``` > threadControl_onDisconnect(); > standardHandlers_onDisconnect(); > > /* > * Cut off the transport immediately. This has the effect of > * cutting off any events that the eventHelper thread might > * be trying to send. > */ > transport_close(); > debugMonitorDestroy(cmdQueueLock); > > /* Reset for a new connection to this VM if it's still alive */ > if ( ! gdata->vmDead ) { > debugInit_reset(getEnv()); <--- calls classTrack_reset() > } But shutting down debug loop does not seem to have effect on ongoing jvmti callback, e.g. thread 4 in the bug report. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Wed Feb 16 02:27:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 16 Feb 2022 02:27:15 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v2] In-Reply-To: <3fT-lfdwit6XNPviQxCDIfCOAqUvv5Mn6kOW43QrB_g=.a7c7fa2b-fcf4-45f6-82a6-2b309c05932c@github.com> References: <3fT-lfdwit6XNPviQxCDIfCOAqUvv5Mn6kOW43QrB_g=.a7c7fa2b-fcf4-45f6-82a6-2b309c05932c@github.com> Message-ID: On Wed, 16 Feb 2022 01:17:12 GMT, Zhengyu Gu wrote: >>> I am not sure if it is possible, but checking bagSize(deletedSignatures) == 0 seems to race against classTrack_reset() where it does not take handlerLock lock. >> >> I had thought of that too, but I think the way `classTrack_reset()` is called, it is likely not possible for there to be a `classTrack_processUnloads()` also coming in because everything is shut down: >> >> ``` >> threadControl_onDisconnect(); >> standardHandlers_onDisconnect(); >> >> /* >> * Cut off the transport immediately. This has the effect of >> * cutting off any events that the eventHelper thread might >> * be trying to send. >> */ >> transport_close(); >> debugMonitorDestroy(cmdQueueLock); >> >> /* Reset for a new connection to this VM if it's still alive */ >> if ( ! gdata->vmDead ) { >> debugInit_reset(getEnv()); <--- calls classTrack_reset() >> } > > But shutting down debug loop does not seem to have effect on ongoing jvmti callback, e.g. thread 4 in the bug report. The thread 4 callback is triggered due to the debugger having requested `CLASS_UNLOAD` events. This is shutdown by `eventHandler_reset()`, which is called by `debugInit_reset()` before it calls `classTrack_reset()`. So that means by the time we get to `classTrack_reset()`, the thread 4 callback is no longer possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From lkorinth at openjdk.java.net Wed Feb 16 17:05:13 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Wed, 16 Feb 2022 17:05:13 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 09:36:38 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > review updates This comment will keep this pull request alive a bit longer. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From coleenp at openjdk.java.net Thu Feb 17 00:48:05 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Feb 2022 00:48:05 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> Message-ID: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> On Mon, 14 Feb 2022 13:05:52 GMT, Alex Menkov wrote: >> ClassLoaderDataGraph::classes_do description says: >> // Walking classes through the ClassLoaderDataGraph include array classes. >> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > reworked do_class_dump This looks like a nice cleanup! Thank you for the test and verification that the format is the same. A couple of minor comments. src/hotspot/share/services/heapDumper.cpp line 2003: > 2001: > 2002: // class ID > 2003: Klass* klass = k; I don't think it's necessary to introduce the variable 'klass' since it's not a loop anymore. src/hotspot/share/services/heapDumper.cpp line 2305: > 2303: ClassLoaderDataGraph::classes_do(&locked_dump_class); > 2304: } > 2305: Universe::basic_type_classes_do(&do_basic_type_array_class_dump); If this is the last use of this function, you could remove this variant of this function from Universe. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7384 From dholmes at openjdk.java.net Thu Feb 17 02:14:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Feb 2022 02:14:04 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> Message-ID: On Tue, 15 Feb 2022 20:17:09 GMT, Chris Plummer wrote: >> I am not sure classTrack_activate() has the problem, but it is called outside of initialization, inside debug loop ... so I assume that event callback might happen. > > I agree. This code is called when the debug agent receives a CLASS_UNLOAD EventRequest (which the debug agent handles by requesting JVMTI GC_FINISH events). So there is nothing that prevents `classTrack_processUnloads()` from being called at the same time. In that case the `classTrack_processUnloads` is racing with the `classTrack_activate` call. I would not expect it to be possible to generate an event in relation to this before things have been "activated". But moving on ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From dholmes at openjdk.java.net Thu Feb 17 02:20:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Feb 2022 02:20:07 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> Message-ID: On Thu, 17 Feb 2022 02:11:13 GMT, David Holmes wrote: >> I agree. This code is called when the debug agent receives a CLASS_UNLOAD EventRequest (which the debug agent handles by requesting JVMTI GC_FINISH events). So there is nothing that prevents `classTrack_processUnloads()` from being called at the same time. > > In that case the `classTrack_processUnloads` is racing with the `classTrack_activate` call. I would not expect it to be possible to generate an event in relation to this before things have been "activated". But moving on ... Okay I see from later comments that in fact no such race exists, but we have to synchronize with cbTrackingObjectFree ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From dholmes at openjdk.java.net Thu Feb 17 02:20:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Feb 2022 02:20:08 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> Message-ID: On Thu, 17 Feb 2022 02:14:05 GMT, David Holmes wrote: >> In that case the `classTrack_processUnloads` is racing with the `classTrack_activate` call. I would not expect it to be possible to generate an event in relation to this before things have been "activated". But moving on ... > > Okay I see from later comments that in fact no such race exists, but we have to synchronize with cbTrackingObjectFree Bah! But then a comment after that says it does exist again. There seem to be issues understanding exactly what the concurrent call sequences can be with this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From dholmes at openjdk.java.net Thu Feb 17 02:28:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Feb 2022 02:28:08 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Simplify classTrack_reset and revert bagSize check The correctness here depends on exactly how these different functions can be called. I would have expected the allowed sequence to be: activate -> 1or more processUnloads -> reset but given processUnloads can somehow occur concurrently with activate, there is obviously more at play here. The main question for me is whether reset can be called more than once and whether it too can be called when processUnloads is still executing? If yes then there are still problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 05:24:06 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 05:24:06 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> Message-ID: On Thu, 17 Feb 2022 02:16:41 GMT, David Holmes wrote: >> Okay I see from later comments that in fact no such race exists, but we have to synchronize with cbTrackingObjectFree > > Bah! But then a comment after that says it does exist again. > > There seem to be issues understanding exactly what the concurrent call sequences can be with this code. I think you might be confusing `classTrack_activate()` with `classTrack_reset()`. I believe the former has a race but the latter does not. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 05:31:04 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 05:31:04 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: <8KHWGoB6r7lHQ-AmxaZsG4pifWLQqHo80iyWn6pvO_U=.1e5adefe-9c55-4c62-9671-087c2bad1ded@github.com> <2RVj6P4L-oh_zjLxSrEDI46xi_OQcNkJqdWlI4rG27Y=.3d81f00a-e04b-4e79-9bee-fbe38daa50a3@github.com> <8k179x4389TeBvn6_PzN38FsCXf7ms3kO2IZ7-5JfZ4=.3a193da8-1906-4ad0-a176-75f7f8033d0b@github.com> Message-ID: On Thu, 17 Feb 2022 05:21:06 GMT, Chris Plummer wrote: >> Bah! But then a comment after that says it does exist again. >> >> There seem to be issues understanding exactly what the concurrent call sequences can be with this code. > > I think you might be confusing `classTrack_activate()` with `classTrack_reset()`. I believe the former has a race but the latter does not. ...and even with the race, I still I think it is safe for a new `bagSize(deletedSignatures) == 0` check to be added outside the lock. The only thing `classTrack_activate()` can do to `deletedSignatures` is set it when it is null. There is no risk of `deletedSignatures` being deleted and reallocated by another thread once you are in `classTrack_processUnloads()`. This is because it is called while holding the `handlerLock`, and as I explained elsewhere, by the time `classTrack_reset()` is called, it's no longer possible to be in `classTrack_processUnloads()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 06:00:11 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 06:00:11 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Simplify classTrack_reset and revert bagSize check processUnloads is continuously called on every event. It's purpose is to process pending CLASS_UNLOAD events that have accumulated since the last JVMTI event. This is a rather hacky solution. JVMTI does not actually send a CLASS_UNLOAD event. It doesn't support them. What it does support is OBJECT_FREE events. So when the debugger has enabled CLASS_UNLOAD events, the debug agent enables OBJECT_FEE events. It tags each j.l.Class instance so it will get the OBJECT_FREE event for them, and when the event comes in, the Class gets added to deletedSignatures so the agent can later notify the debugger about it. As a side note, this OBJECT_FREE solution is somewhat new. The old solution was to always do an "allClasses" during initialization, and then diff that with "allClasses" every time there was a full GC to see which classes unloaded. I wonder now if there isn't a reason we just don't send the CLASS_UNLOAD when the OBJECT_FREE is received. It would probably greatly simplify classTrack.c, and will fix an outstanding bug we have where sometimes there is a lengthy delay before CLASS_UNLOAD events are sent. This is because once there is a GC, they events are not sent until the next JVMTI event. It's actually possible there would never be one if the only thing the debugger is requesting is CLASS_UNLOAD events. Anyway, back to processUnloads synchronization. The reason for synchronization between processUnload and activate is because one thread could be handling some random JVMTI event (maybe a breakpoint) and is calling processUnloads, and at the same time another thread is handling a CLASS_UNLOAD event request from the debugger, and calling activate. But now that I think of it, this should be harmless even without synchronization. The processUnloads thread will see the allocated deletedSignatures if activate has gotten that far, otherwise it won't. It should behave correctly in either case. I'm not convince that activate even needs synchronization. The purpose of the classTrack synchronization is to prevent one thread in processUnloads from grabbing and using deletedSignatures, only to have another thread in processUnloads do the same, and delete deletedSignatures in the process, leaving the 1st thread holding onto a deallocated pointer. However, even this should not be possible because a ll callers to processUnloads have already grabbed the handlerLock. What I'm tempted to say here is just have this PR keep all the synchronization and I'll file a CR to possibly do a lot of cleanup here. Either remove (maybe all of) the synchronization, or maybe even implement sending the CLASS_UNLOAD when the OBJECT_FREE comes in, which will make the synchronization question moot, and also fix that other bug I mentioned. BTW, one other bit of nonsense. classTrack_activate() does: deletedSignatures = bagCreateBag(sizeof(char*), 1000); This will be deleted the very first time an event comes in, even if no classes were unloaded, and processUnloads replaces it with: deletedSignatures = bagCreateBag(sizeof(char*), 10); ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 07:01:07 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 07:01:07 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Simplify classTrack_reset and revert bagSize check Actually a bit of a correction to my last statement above. processUnloads is only called if there has been a GC since the last event came in. This also reduces the need to optimize processUnloads for the case where deletedSignatures is NULL or is empty. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From dholmes at openjdk.java.net Thu Feb 17 07:52:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Feb 2022 07:52:08 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 06:57:07 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify classTrack_reset and revert bagSize check > > Actually a bit of a correction to my last statement above. processUnloads is only called if there has been a GC since the last event came in. This also reduces the need to optimize processUnloads for the case where deletedSignatures is NULL or is empty. Thanks for the additional explanation @plummercj. I agree with your suggestion to move this forward and revisit. I suspect the issue with directly issuing the CLASS_UNLOAD event is due to when, and on what thread, the OBJECT_FREE event is issued. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From amenkov at openjdk.java.net Thu Feb 17 12:48:11 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 17 Feb 2022 12:48:11 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> Message-ID: On Thu, 17 Feb 2022 00:34:04 GMT, Coleen Phillimore wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> reworked do_class_dump > > src/hotspot/share/services/heapDumper.cpp line 2305: > >> 2303: ClassLoaderDataGraph::classes_do(&locked_dump_class); >> 2304: } >> 2305: Universe::basic_type_classes_do(&do_basic_type_array_class_dump); > > If this is the last use of this function, you could remove this variant of this function from Universe. It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses() ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Thu Feb 17 12:54:48 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 17 Feb 2022 12:54:48 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4] In-Reply-To: References: Message-ID: <0IUcZUgqXwXyfxYG-zcRIs0EJ2I5BSSTmSN5Yi5o8Ow=.dd0f7675-a4e4-4591-b1d9-27408c881297@github.com> > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7384/files - new: https://git.openjdk.java.net/jdk/pull/7384/files/173a8da8..fcb8b0a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384 PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Thu Feb 17 12:54:50 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 17 Feb 2022 12:54:50 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3] In-Reply-To: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> Message-ID: On Thu, 17 Feb 2022 00:31:50 GMT, Coleen Phillimore wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> reworked do_class_dump > > src/hotspot/share/services/heapDumper.cpp line 2003: > >> 2001: >> 2002: // class ID >> 2003: Klass* klass = k; > > I don't think it's necessary to introduce the variable 'klass' since it's not a loop anymore. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From zgu at openjdk.java.net Thu Feb 17 13:32:09 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 17 Feb 2022 13:32:09 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 06:57:07 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify classTrack_reset and revert bagSize check > > Actually a bit of a correction to my last statement above. processUnloads is only called if there has been a GC since the last event came in. This also reduces the need to optimize processUnloads for the case where deletedSignatures is NULL or is empty. > Thanks for the additional explanation @plummercj. I agree with your suggestion to move this forward and revisit. > > I suspect the issue with directly issuing the CLASS_UNLOAD event is due to when, and on what thread, the OBJECT_FREE event is issued. I believe OBJECT_FREE event is always issued from VMThread, at a GC safepoint prior to JDK16 or a dedicated safepoint post. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Thu Feb 17 13:45:05 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 17 Feb 2022 13:45:05 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 02:25:15 GMT, David Holmes wrote: > The correctness here depends on exactly how these different functions can be called. I would have expected the allowed sequence to be: activate -> 1or more processUnloads -> reset > > but given processUnloads can somehow occur concurrently with activate, there is obviously more at play here. The main question for me is whether reset can be called more than once and whether it too can be called when processUnloads is still executing? If yes then there are still problems. `classTrack_activate()` is called inside `debugLoop_run()`, so it looks like that jvmti callback is enabled at the time. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libjdwp.so+0xf0ea] classTrack_activate+0x3a C [libjdwp.so+0x166dd] installHandler+0xdd C [libjdwp.so+0x618c] setCommand+0x17c C [libjdwp.so+0x13cd9] debugLoop_run+0x299 C [libjdwp.so+0x275e4] attachThread+0x54 V [libjvm.so+0x12be611] JvmtiAgentThread::call_start_function()+0x181 V [libjvm.so+0x1a9e496] JavaThread::thread_main_inner()+0x5c6 V [libjvm.so+0x1aa7100] Thread::call_run()+0x100 V [libjvm.so+0x1666814] thread_native_entry(Thread*)+0x104 ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Thu Feb 17 13:53:10 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 17 Feb 2022 13:53:10 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 05:57:24 GMT, Chris Plummer wrote: > processUnloads is continuously called on every event. It's purpose is to process pending CLASS_UNLOAD events that have accumulated since the last JVMTI event. This is a rather hacky solution. JVMTI does not actually send a CLASS_UNLOAD event. It doesn't support them. What it does support is OBJECT_FREE events. So when the debugger has enabled CLASS_UNLOAD events, the debug agent enables OBJECT_FEE events. It tags each j.l.Class instance so it will get the OBJECT_FREE event for them, and when the event comes in, the Class gets added to deletedSignatures so the agent can later notify the debugger about it. > > As a side note, this OBJECT_FREE solution is somewhat new. The old solution was to always do an "allClasses" during initialization, and then diff that with "allClasses" every time there was a full GC to see which classes unloaded. I wonder now if there isn't a reason we just don't send the CLASS_UNLOAD when the OBJECT_FREE is received. It would probably greatly simplify classTrack.c, and will fix an outstanding bug we have where sometimes there is a lengthy delay before CLASS_UNLOAD events are sent. This is because once there is a GC, they events are not sent until the next JVMTI event. It's actually possible there would never be one if the only thing the debugger is requesting is CLASS_UNLOAD events. > > Anyway, back to processUnloads synchronization. The reason for synchronization between processUnload and activate is because one thread could be handling some random JVMTI event (maybe a breakpoint) and is calling processUnloads, and at the same time another thread is handling a CLASS_UNLOAD event request from the debugger, and calling activate. But now that I think of it, this should be harmless even without synchronization. The processUnloads thread will see the allocated deletedSignatures if activate has gotten that far, otherwise it won't. It should behave correctly in either case. I'm not convince that activate even needs synchronization. The purpose of the classTrack synchronization is to prevent one thread in processUnloads from grabbing and using deletedSignatures, only to have another thread in processUnloads do the same, and delete deletedSignatures in the process, leaving the 1st thread holding onto a deallocated pointer. However, even this should not be possible because all callers to processUnloads have already grabbed the handlerLock. > > What I'm tempted to say here is just have this PR keep all the synchronization and I'll file a CR to possibly do a lot of cleanup here. Either remove (maybe all of) the synchronization, or maybe even implement sending the CLASS_UNLOAD when the OBJECT_FREE comes in, which will make the synchronization question moot, and also fix that other bug I mentioned. > > BTW, one other bit of nonsense. classTrack_activate() does: > > ``` > deletedSignatures = bagCreateBag(sizeof(char*), 1000); > ``` > > This will be deleted the very first time an event comes in, even if no classes were unloaded, and processUnloads replaces it with: > > ``` > deletedSignatures = bagCreateBag(sizeof(char*), 10); > ``` I believe checking `bagSize() == 0` is an optimization. I think just taking `handlerLock` lock before calling `classTrack_reset()` ensures no race can happen and seems harmless. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From coleenp at openjdk.java.net Thu Feb 17 16:35:03 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Feb 2022 16:35:03 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4] In-Reply-To: References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> Message-ID: On Thu, 17 Feb 2022 12:45:10 GMT, Alex Menkov wrote: >> src/hotspot/share/services/heapDumper.cpp line 2305: >> >>> 2303: ClassLoaderDataGraph::classes_do(&locked_dump_class); >>> 2304: } >>> 2305: Universe::basic_type_classes_do(&do_basic_type_array_class_dump); >> >> If this is the last use of this function, you could remove this variant of this function from Universe. > > It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses() > void Universe::basic_type_classes_do(void f(Klass*)) { This one is unused. The other one that takes the Closure is the one that getClassLoaderClasses() calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From tschatzl at openjdk.java.net Thu Feb 17 16:55:04 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 17 Feb 2022 16:55:04 GMT Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang wrote: > Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc. > > Test: tier1-6 Looks good. That comment about `git diff --color-moved=zebra` really helped. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7482 From cjplummer at openjdk.java.net Thu Feb 17 17:14:10 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 17:14:10 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 13:29:11 GMT, Zhengyu Gu wrote: > I suspect the issue with directly issuing the CLASS_UNLOAD event is due to when, and on what thread, the OBJECT_FREE event is issued. Yes, I think there is an issue trying to send all the accumulated CLASS_UNLOAD events when the GC_FINISH arrives because it arrives on a VM thread, not a java thread. The debug agent may suspend whichever thread sent the JDWP event to the debugger, and it will stay suspended until the debugger tells the debug agent to resume the thread. I say "may suspend" because it depends on the suspend policy of the EventRequest. It will suspend if the policy is SUSPEND_THREAD or SUSPEND_ALL, but not for SUSPEND_NONE. So we have two problems then. The VM thread is suspended, and also the debugger sees the VM thread as the event thread (only java threads should be event threads). I assume OBJECT_FREE also arrives on a VM thread and would have the same issue if it triggered sending the CLASS_UNLOAD event right away. To fix the issue of having to wait for the next event before sending the CLASS_UNLOAD events (and it sometimes being a long time in coming), the debug agent could enable a JVMTI event it knows will be triggered right away, such as MethodEntry or MethodExit (these might be the only two candidates). This at least would ensure triggering the calling of processUnloads right way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 17:30:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 17:30:15 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Simplify classTrack_reset and revert bagSize check Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 17:30:15 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 17:30:15 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 13:49:52 GMT, Zhengyu Gu wrote: > I believe checking `bagSize() == 0` is an optimization. I think just taking `handlerLock` lock before calling `classTrack_reset()` ensures no race can happen and seems harmless. Yes, it would be an optimization, and one I'm now seeing is not really needed since processUnloads() is not called as frequently as I thought (only called after a GC completes). The grabbing of the handlerLock is questionable. Kim also called it out in [JDK-8256811](https://bugs.openjdk.java.net/browse/JDK-8256811): ``` I think this can be fixed by removing the conditionalization of the call to classTrack_processUnloads, and just do it unconditionally. There is a (somewhat confusing) comment saying that the conditionalization is there to avoid taking the handler lock when that isn't needed. But it's not clear why that lock is being taken on that code path at all, as classTrack_processUnloads contains it's own internal locking. ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Thu Feb 17 17:38:13 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 17:38:13 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 13:42:13 GMT, Zhengyu Gu wrote: > `classTrack_activate()` is called inside `debugLoop_run()`, so it looks like that jvmti callback is enabled at the time. Yes. This is due to the debugger sending a JDWP EventRequest command for CLASS_UNLOAD events. At that point class tracking is activated and the debug agent enables OBJECT_FREE events. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From amenkov at openjdk.java.net Thu Feb 17 17:40:19 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 17 Feb 2022 17:40:19 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4] In-Reply-To: References: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com> <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com> Message-ID: On Thu, 17 Feb 2022 16:32:07 GMT, Coleen Phillimore wrote: >> It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses() > >> void Universe::basic_type_classes_do(void f(Klass*)) { > This one is unused. The other one that takes the Closure is the one that getClassLoaderClasses() calls. I thought we always have 2 version (for function pointer and closure object), Universe::metaspace_pointers_do has only version for closures. Will remove unused one. ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From amenkov at openjdk.java.net Thu Feb 17 18:24:47 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 17 Feb 2022 18:24:47 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5] In-Reply-To: References: Message-ID: > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: removed unused Universe::basic_type_classes_do ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7384/files - new: https://git.openjdk.java.net/jdk/pull/7384/files/fcb8b0a6..2c787184 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=03-04 Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384 PR: https://git.openjdk.java.net/jdk/pull/7384 From coleenp at openjdk.java.net Thu Feb 17 19:29:15 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Feb 2022 19:29:15 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 18:24:47 GMT, Alex Menkov wrote: >> ClassLoaderDataGraph::classes_do description says: >> // Walking classes through the ClassLoaderDataGraph include array classes. >> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > removed unused Universe::basic_type_classes_do Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7384 From cjplummer at openjdk.java.net Thu Feb 17 20:55:14 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 20:55:14 GMT Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 18:24:47 GMT, Alex Menkov wrote: >> ClassLoaderDataGraph::classes_do description says: >> // Walking classes through the ClassLoaderDataGraph include array classes. >> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > removed unused Universe::basic_type_classes_do Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From cjplummer at openjdk.java.net Thu Feb 17 23:30:24 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Feb 2022 23:30:24 GMT Subject: RFR: 8282076: Merge some debug agent changes from the loom repo Message-ID: There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. ------------- Commit messages: - Merge some loom changes that are not vthread specific. Changes: https://git.openjdk.java.net/jdk/pull/7524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282076 Stats: 116 lines in 3 files changed: 61 ins; 45 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7524/head:pull/7524 PR: https://git.openjdk.java.net/jdk/pull/7524 From amenkov at openjdk.java.net Fri Feb 18 09:25:57 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 18 Feb 2022 09:25:57 GMT Subject: Integrated: 8281267: VM HeapDumper dumps array classes several times In-Reply-To: References: Message-ID: <5gfCGRUQ5cBqTu-9a9UGSV9QhgzjaAG4hHpcBGIl-XE=.6cf9af38-84b3-475a-8942-0855c47aef6d@github.com> On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov wrote: > ClassLoaderDataGraph::classes_do description says: > // Walking classes through the ClassLoaderDataGraph include array classes. > So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do) This pull request has now been integrated. Changeset: 138a1719 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/138a17195d1695c6faaa156a43624c39c62b141b Stats: 463 lines in 4 files changed: 348 ins; 73 del; 42 mod 8281267: VM HeapDumper dumps array classes several times Reviewed-by: cjplummer, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/7384 From serb at openjdk.java.net Fri Feb 18 22:30:53 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 18 Feb 2022 22:30:53 GMT Subject: RFR: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition In-Reply-To: References: <0_-AS4joC1SWs7K_0XQPYFloJj7DlPHXOhsP5xPrWT8=.3eded7b8-3338-40ee-bc77-0648ce04f2c9@github.com> Message-ID: On Tue, 11 Jan 2022 14:21:06 GMT, zzambers wrote: >> @zzambers please integrate this (see bot comment above) and I'll sponsor the push for you. > > @jerboaa @sspitsyn @alexmenkov thanks for help and reviews @zzambers do you plan to backport these changes to the old releases and to the jdk8 where this test started to fail? ------------- PR: https://git.openjdk.java.net/jdk/pull/6652 From cjplummer at openjdk.java.net Sat Feb 19 04:07:01 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 19 Feb 2022 04:07:01 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr Message-ID: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: ` * @requires vm.opt.DeoptimizeALot != true` When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. ------------- Commit messages: - Move @requires to the correct test case. Changes: https://git.openjdk.java.net/jdk/pull/7542/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7542&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281614 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7542/head:pull/7542 PR: https://git.openjdk.java.net/jdk/pull/7542 From dcubed at openjdk.java.net Sat Feb 19 14:35:49 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 19 Feb 2022 14:35:49 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: <-pbF0GOX1_0xsf2Auzu9f90xfEtjQ0bHen06aUcYJLw=.55d23721-f0bf-4d8d-840d-ed3c4335418c@github.com> On Sat, 19 Feb 2022 04:00:30 GMT, Chris Plummer wrote: > This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: > > ` * @requires vm.opt.DeoptimizeALot != true` > > When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7542 From shade at openjdk.java.net Mon Feb 21 11:01:24 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 21 Feb 2022 11:01:24 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test Message-ID: There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. Additional testing: - [x] New test on Linux x86_64 fastdebug - [x] New test on Linux x86_64 release - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7554/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7554&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282170 Stats: 1127 lines in 2 files changed: 1127 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7554/head:pull/7554 PR: https://git.openjdk.java.net/jdk/pull/7554 From aturbanov at openjdk.java.net Mon Feb 21 12:12:55 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 12:12:55 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: <2CRv7WmchPOB1TD4QQq738ZIJvU5Els5DfhtZv0dQak=.231cd6a0-90f8-4ba2-a984-7e795d73b58b@github.com> On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (clazz.isInstance(obj)) { > > Replacement is equivalent if it's known that `obj != null`. > In JDK codebase there are many such places. > > I tried to measure performance via JMH > > Class integerClass = Integer.class; > Class numberClass = Number.class; > > Object integerObject = 45666; > Object doubleObject = 8777d; > > @Benchmark > public boolean integerInteger_isInstance() { > return integerClass.isInstance(integerObject); > } > > @Benchmark > public boolean integerInteger_isAssignableFrom() { > return integerClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public boolean integerDouble_isInstance() { > return integerClass.isInstance(doubleObject); > } > > @Benchmark > public boolean integerDouble_isAssignableFrom() { > return integerClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberDouble_isInstance() { > return numberClass.isInstance(doubleObject); > } > > @Benchmark > public boolean numberDouble_isAssignableFrom() { > return numberClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberInteger_isInstance() { > return numberClass.isInstance(integerObject); > } > > @Benchmark > public boolean numberInteger_isAssignableFrom() { > return numberClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public void numberIntegerDouble_isInstance(Blackhole bh) { > bh.consume(numberClass.isInstance(integerObject)); > bh.consume(numberClass.isInstance(doubleObject)); > } > > @Benchmark > public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { > bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); > bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); > } > > `isInstance` is a bit faster than `isAssignableFrom` > > Benchmark Mode Cnt Score Error Units > integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op > integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op > integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op > numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op > integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op > integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op > numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op > numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op > numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op > numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op First of all, I did check that replace is definitely valid. public static void main(String[] args) { List> classes = List.of(Integer.class, Number.class, Serializable.class, boolean.class, byte.class, short.class, int.class, long.class, char.class, float.class, double.class, Boolean.TYPE, Byte.TYPE, Short.TYPE, Integer.TYPE, Long.TYPE, Character.TYPE, Float.TYPE, Double.TYPE, Boolean.class, Byte.class, Short.class, Integer.class, Long.class, Character.class, Float.class, Double.class); List objects = List.of( new Integer(4), new BigInteger("345345"), new StringBuilder("df"), true, false, (byte)1, (byte)0, (short)1, (short)0, (int)1, (int)0, 1L, 0L, (char)1, (char)0, 1f, 0f, 1d, 0d, new Boolean(true), new Byte((byte)3), new Short((short)4), new Integer(5), new Long(6), new Character((char)7), new Float(8f), new Double(9d), new ClassInstanceAssignableCheck()); for (Class clazz : classes) { System.out.println("Check " + clazz); for (Object object : objects) { checkIsSave(object, clazz); } System.out.println(); } } private static void checkIsSave(@Nonnull Object object, @Nonnull Class clazz) { boolean isInstance = clazz.isInstance(object); boolean assignableFrom = clazz.isAssignableFrom(object.getClass()); System.out.println(" " + object + " of class " + object.getClass().getSimpleName() + " check with " + clazz.getSimpleName() + ": isInstance=" + isInstance + " isAssignableFrom=" + assignableFrom); if (isInstance != assignableFrom) { throw new RuntimeException("Not matched for " + object + " and " + clazz); } } >What client tests have you run that touch the code you are changing ? I did run tier4. It includes all client tests as I know. Some of them failed, when I run in batch. But I rechecked all failed tests one-by-one and they are fine. Can you suggest which test better to run? ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aturbanov at openjdk.java.net Mon Feb 21 12:19:52 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 12:19:52 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 01:34:20 GMT, Phil Race wrote: >In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it. I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_ operator. And `isInstance` method javadoc is very straight forward: `This method is the dynamic equivalent of the Java language instanceof operator.` Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that: 1. [Wrong isAssignableFrom test when adding Principal to Subject ](https://bugs.openjdk.java.net/browse/JDK-8034820) 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8254717) 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800) So, it gives all 3 points to prefer isInstance method: it's shorter, it's clearer for most java developers, it's faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From duke at openjdk.java.net Mon Feb 21 14:51:11 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Mon, 21 Feb 2022 14:51:11 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 Message-ID: Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. ------------- Commit messages: - Fix AsyncGetCallTrace bug Changes: https://git.openjdk.java.net/jdk/pull/7559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282200 Stats: 25 lines in 2 files changed: 19 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7559/head:pull/7559 PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Mon Feb 21 15:02:53 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Mon, 21 Feb 2022 15:02:53 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Related to https://github.com/openjdk/jdk/pull/7193 ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From plevart at openjdk.java.net Mon Feb 21 20:29:54 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 21 Feb 2022 20:29:54 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 08:28:35 GMT, Erik Gahlin wrote: >> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405: >> >>> 403: Object res = m.invoke(a, new Object[0]); >>> 404: if (res instanceof Annotation[]) { >>> 405: for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) { >> >> BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead? > > It looks unnecessary. Please feel free to fix. Or even use the new pattern matching syntax and remove unnecessary explicit empty array construction: if (m.invoke(a) instanceof Annotation[] anns) { for (Annotation rep : anns) { ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From dholmes at openjdk.java.net Mon Feb 21 20:40:56 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Feb 2022 20:40:56 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. I marking this as changes requested because I need to investigate further. A `shouldNotReachHere` should never be reached, if it can be reached then the circumstances need investigated to see where the true problem lies. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Mon Feb 21 21:17:46 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Mon, 21 Feb 2022 21:17:46 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. I'm willing to help... The described error is not dependent on the JVM being a debug build, I can also reproduce it with a release build by decreasing the sampling interval. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From dholmes at openjdk.java.net Tue Feb 22 01:00:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 01:00:45 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Please see updates to JBS issue and the draft PR here: https://github.com/openjdk/jdk/pull/7566 You can either take my changes, or hand over to me and I will use my PR. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Tue Feb 22 08:43:47 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 22 Feb 2022 08:43:47 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. To be frank, I would like to integrate your changes into my, because I need a second PR for JDK to be able to write such issues in JBS on my own. To the PR itself: The main difference between both is that with my PR we say "this should not happen please check before if you really want this" and with your PR we don't. I liked your initial PR that threw an error for the normal case that we cannot call this method for a thread in an inconsistent state. As you stated in the comment in the method of your PR, it is only a special case for AsyncGetCallTrace. What is the down side of having to explicitly check for this special case when you need it and otherwise throw an error? ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From dholmes at openjdk.java.net Tue Feb 22 12:05:50 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 12:05:50 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. I don't like unnecessary special-cases. I added the `ShouldNotReachHere()` due to flawed reasoning, so would like to remove it again and make the code look the way it would have if I had realized about AGCT at the time. Creating a new API just for AGCT to use is not necessary IMO. Cheers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Tue Feb 22 12:13:52 2022 From: duke at openjdk.java.net (zzambers) Date: Tue, 22 Feb 2022 12:13:52 GMT Subject: RFR: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition In-Reply-To: References: <0_-AS4joC1SWs7K_0XQPYFloJj7DlPHXOhsP5xPrWT8=.3eded7b8-3338-40ee-bc77-0648ce04f2c9@github.com> Message-ID: <1d39j-TR_yxfWCO3WNNrwJh0QScjlrQsMIYHqdnVhQw=.de810d84-70ab-42ec-8474-1710770bd12b@github.com> On Fri, 18 Feb 2022 22:27:32 GMT, Sergey Bylokhov wrote: >> @jerboaa @sspitsyn @alexmenkov thanks for help and reviews > > @zzambers do you plan to backport these changes to the old releases and to the jdk8 where this test started to fail? @mrserb, I have just created jdk8 backport yesterday and I will probably do other ones soon. Sorry for the delay. ------------- PR: https://git.openjdk.java.net/jdk/pull/6652 From duke at openjdk.java.net Tue Feb 22 12:43:46 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 22 Feb 2022 12:43:46 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Good to know. I will change my PR accordingly (if this ok for you) :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From zgu at openjdk.java.net Tue Feb 22 16:00:51 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 22 Feb 2022 16:00:51 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 17:34:41 GMT, Chris Plummer wrote: >>> The correctness here depends on exactly how these different functions can be called. I would have expected the allowed sequence to be: activate -> 1or more processUnloads -> reset >>> >>> but given processUnloads can somehow occur concurrently with activate, there is obviously more at play here. The main question for me is whether reset can be called more than once and whether it too can be called when processUnloads is still executing? If yes then there are still problems. >> >> `classTrack_activate()` is called inside `debugLoop_run()`, so it looks like that jvmti callback is enabled at the time. >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> C [libjdwp.so+0xf0ea] classTrack_activate+0x3a >> C [libjdwp.so+0x166dd] installHandler+0xdd >> C [libjdwp.so+0x618c] setCommand+0x17c >> C [libjdwp.so+0x13cd9] debugLoop_run+0x299 >> C [libjdwp.so+0x275e4] attachThread+0x54 >> V [libjvm.so+0x12be611] JvmtiAgentThread::call_start_function()+0x181 >> V [libjvm.so+0x1a9e496] JavaThread::thread_main_inner()+0x5c6 >> V [libjvm.so+0x1aa7100] Thread::call_run()+0x100 >> V [libjvm.so+0x1666814] thread_native_entry(Thread*)+0x104 > >> `classTrack_activate()` is called inside `debugLoop_run()`, so it looks like that jvmti callback is enabled at the time. > > Yes. This is due to the debugger sending a JDWP EventRequest command for CLASS_UNLOAD events. At that point class tracking is activated and the debug agent enables OBJECT_FREE events. @plummercj Thanks for the review. @dholmes-ora Are you okay with current version? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 22 18:55:51 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Feb 2022 18:55:51 GMT Subject: RFR: 8282076: Merge some debug agent changes from the loom repo In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:32:14 GMT, Chris Plummer wrote: > There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. > > The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. > > In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. > > ### Tests: > - [x] vmTestbase/nsk/jdb > - [x] vmTestbase/nsk/jdi > - [x] vmTestbase/nsk/jdwp > - [x] serviceability/jdwp > - [x] jdk/com/sun/jdi Ping! I could still use 2 reviewers. The changes are pretty simple. It's just a bit or restructuring with no logic changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7524 From cjplummer at openjdk.java.net Tue Feb 22 18:56:51 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Feb 2022 18:56:51 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: <-pbF0GOX1_0xsf2Auzu9f90xfEtjQ0bHen06aUcYJLw=.55d23721-f0bf-4d8d-840d-ed3c4335418c@github.com> References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> <-pbF0GOX1_0xsf2Auzu9f90xfEtjQ0bHen06aUcYJLw=.55d23721-f0bf-4d8d-840d-ed3c4335418c@github.com> Message-ID: On Sat, 19 Feb 2022 14:33:03 GMT, Daniel D. Daugherty wrote: > Thumbs up. Thanks Dan! Can I get one more reviewer please? ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From cjplummer at openjdk.java.net Tue Feb 22 19:57:50 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Feb 2022 19:57:50 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 10:55:42 GMT, Aleksey Shipilev wrote: > There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. > > Additional testing: > - [x] New test on Linux x86_64 fastdebug > - [x] New test on Linux x86_64 release > - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release So you load a class 50 times in separate ClassLoaders, and each load triggers the ClassPrepare event, and each time that happens you set a breakpoint on each of the 1000 methods, meaning a total of 5000 breakpoints. Doing this will eventually trigger calling CollectorPolicy::satisfy_failed_metadata_allocation(). Previous to the [8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) fix, this used to trigger an assert. Am I understanding this properly? ------------- PR: https://git.openjdk.java.net/jdk/pull/7554 From dholmes at openjdk.java.net Tue Feb 22 21:15:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 21:15:46 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Please do update. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From dholmes at openjdk.java.net Tue Feb 22 21:27:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 21:27:48 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Sat, 19 Feb 2022 04:00:30 GMT, Chris Plummer wrote: > This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: > > ` * @requires vm.opt.DeoptimizeALot != true` > > When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. Sorry Chris but things still seem a bit confused to me. David test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 49: > 47: * @bug 8193124 > 48: * @summary Test the clhsdb 'findpc' command with Xcomp on core file > 49: * @requires vm.compMode != "Xcomp" The summary says "with Xcomp" but the requires says "!= Xcomp" ??? test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 61: > 59: * @bug 8193124 > 60: * @summary Test the clhsdb 'findpc' command w/o Xcomp on live process > 61: * @requires vm.hasSA Summary says w/o xcomp but no requires clause to reject Xcomp mode ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From dholmes at openjdk.java.net Tue Feb 22 21:36:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 21:36:49 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: References: Message-ID: <1EzTeqnEJSS5e0tKSNmMCG20cKbiTxoim49wJ_DvyKM=.c3501117-7681-4544-80f2-a9142c5282b2@github.com> On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Simplify classTrack_reset and revert bagSize check Changes seem reasonable given the discussion. Thanks, David I thought from: https://github.com/openjdk/jdk/pull/7461#issuecomment-1043215122 there was srtill an outstanding issue with the handlerLock ? Though @plummercj seems to have approved anyway. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 91: > 89: * > 90: * Note: jvmtiAllocate/jvmtiDeallocate() may be blocked by ongoing safepoints. > 91: * It is dangerous to call them (via bagCreateBag/bagDestroyBag())while holding monitor(s), Nit: need space after )) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Tue Feb 22 22:05:21 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 22 Feb 2022 22:05:21 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v5] In-Reply-To: References: Message-ID: <6JnKTtpCblPeKb6MshzbTAoJeWswsKuU4d4ime6epFw=.ea650145-3867-403c-bccc-b379fb73a54c@github.com> > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Missing space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7461/files - new: https://git.openjdk.java.net/jdk/pull/7461/files/f93bf8d6..78198bb3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7461&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7461.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7461/head:pull/7461 PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Tue Feb 22 22:58:49 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Feb 2022 22:58:49 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Tue, 22 Feb 2022 21:22:50 GMT, David Holmes wrote: >> This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: >> >> ` * @requires vm.opt.DeoptimizeALot != true` >> >> When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. > > test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 49: > >> 47: * @bug 8193124 >> 48: * @summary Test the clhsdb 'findpc' command with Xcomp on core file >> 49: * @requires vm.compMode != "Xcomp" > > The summary says "with Xcomp" but the requires says "!= Xcomp" ??? Xcomp is in reference to how the debuggee is launched, and that is controlled by the test. See next comment for more. > test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 61: > >> 59: * @bug 8193124 >> 60: * @summary Test the clhsdb 'findpc' command w/o Xcomp on live process >> 61: * @requires vm.hasSA > > Summary says w/o xcomp but no requires clause to reject Xcomp mode I think that is related to why xcomp-process and xcomp-core are not in agreement. Probably also a bug introduced when adding the two core tests (just like the DeoptimizeALot check was done wrong). As a reference, here's what it looked like before adding the two core tests: * @requires vm.hasSA * @requires vm.compiler1.enabled * @requires vm.opt.DeoptimizeALot != true * @run main/othervm/timeout=480 ClhsdbFindPC true * @requires vm.compMode != "Xcomp" * @requires vm.hasSA * @requires vm.compiler1.enabled * @run main/othervm/timeout=480 ClhsdbFindPC false The first test is running the debuggee with -Xcomp. The test itself can be run with or without -Xcomp. The second runs the debuggee without -Xcomp. In this case the test is not allowed to be run with -Xcomp, because it would be passed to the debuggee (although with some work the test could have stripped it). I believe Leonid added this restriction to avoid unnecessarily testing the debuggee in -Xcomp mode twice. To be it consistent it looks like I need to move the `@requires vm.compMode != "Xcomp"` from `id=xcomp-core` to `no-xcomp-process`. The other choice is to just remove this restriction. I wasn't a fan of it when it went in initially. ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From cjplummer at openjdk.java.net Tue Feb 22 23:04:48 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Feb 2022 23:04:48 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v5] In-Reply-To: <6JnKTtpCblPeKb6MshzbTAoJeWswsKuU4d4ime6epFw=.ea650145-3867-403c-bccc-b379fb73a54c@github.com> References: <6JnKTtpCblPeKb6MshzbTAoJeWswsKuU4d4ime6epFw=.ea650145-3867-403c-bccc-b379fb73a54c@github.com> Message-ID: <72ZVQkE-2iTI8Ub_YFSVuXyjVmlq4sgI9Vi4yXrI2Mc=.e3cf65c2-8344-4c3f-98ea-d526d8b240bd@github.com> On Tue, 22 Feb 2022 22:05:21 GMT, Zhengyu Gu wrote: >> There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. >> >> **Java Thread** >> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event >> - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. >> - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. >> - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. >> >> If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) >> >> **VM Thread** >> - post `JVMTI_EVENT_OBJECT_FREE` >> - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event >> - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock >> >> From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. >> >> The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. >> >> >> Test: >> - [x] tier1 >> - [x] vmTestbase_nsk_jdi >> - [x] vmTestbase_nsk_jdwp >> - [x] vmTestbase_nsk_jvmti > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Missing space > I thought from: > [#7461 (comment)](https://github.com/openjdk/jdk/pull/7461#issuecomment-1043215122) > there was srtill an outstanding issue with the handlerLock ? Though @plummercj seems to have approved anyway. That's was just part of the discussion as to how much locking is really needed, and we agreed not to address those issues in this PR. So the code is (and already was) probably over synchronized, but that's ok and maybe we can address it at a later point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From dcubed at openjdk.java.net Wed Feb 23 00:54:47 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Feb 2022 00:54:47 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Tue, 22 Feb 2022 22:38:08 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java line 61: >> >>> 59: * @bug 8193124 >>> 60: * @summary Test the clhsdb 'findpc' command w/o Xcomp on live process >>> 61: * @requires vm.hasSA >> >> Summary says w/o xcomp but no requires clause to reject Xcomp mode > > I think that is related to why xcomp-process and xcomp-core are not in agreement. Probably also a bug introduced when adding the two core tests (just like the DeoptimizeALot check was done wrong). As a reference, here's what it looked like before adding the two core tests: > > > * @requires vm.hasSA > * @requires vm.compiler1.enabled > * @requires vm.opt.DeoptimizeALot != true > * @run main/othervm/timeout=480 ClhsdbFindPC true > > * @requires vm.compMode != "Xcomp" > * @requires vm.hasSA > * @requires vm.compiler1.enabled > * @run main/othervm/timeout=480 ClhsdbFindPC false > > The first test is running the debuggee with -Xcomp. The test itself can be run with or without -Xcomp. The second runs the debuggee without -Xcomp. In this case the test is not allowed to be run with -Xcomp, because it would be passed to the debuggee (although with some work the test could have stripped it). I believe Leonid added this restriction to avoid unnecessarily testing the debuggee in -Xcomp mode twice. To be it consistent it looks like I need to move the `@requires vm.compMode != "Xcomp"` from `id=xcomp-core` to `no-xcomp-process`. The other choice is to just remove this restriction. I wasn't a fan of it when it went in initially. Personally, I'm not a fan of running the debugger/debuggee tests with the debugger in -Xcomp mode. I don't think that represents a real world usage scenario. Exercising the debuggee in -Xcomp mode is useful IMHO. ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From cjplummer at openjdk.java.net Wed Feb 23 01:32:58 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 23 Feb 2022 01:32:58 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Wed, 23 Feb 2022 00:51:40 GMT, Daniel D. Daugherty wrote: >> I think that is related to why xcomp-process and xcomp-core are not in agreement. Probably also a bug introduced when adding the two core tests (just like the DeoptimizeALot check was done wrong). As a reference, here's what it looked like before adding the two core tests: >> >> >> * @requires vm.hasSA >> * @requires vm.compiler1.enabled >> * @requires vm.opt.DeoptimizeALot != true >> * @run main/othervm/timeout=480 ClhsdbFindPC true >> >> * @requires vm.compMode != "Xcomp" >> * @requires vm.hasSA >> * @requires vm.compiler1.enabled >> * @run main/othervm/timeout=480 ClhsdbFindPC false >> >> The first test is running the debuggee with -Xcomp. The test itself can be run with or without -Xcomp. The second runs the debuggee without -Xcomp. In this case the test is not allowed to be run with -Xcomp, because it would be passed to the debuggee (although with some work the test could have stripped it). I believe Leonid added this restriction to avoid unnecessarily testing the debuggee in -Xcomp mode twice. To be it consistent it looks like I need to move the `@requires vm.compMode != "Xcomp"` from `id=xcomp-core` to `no-xcomp-process`. The other choice is to just remove this restriction. I wasn't a fan of it when it went in initially. > > Personally, I'm not a fan of running the debugger/debuggee tests with the debugger in -Xcomp mode. > I don't think that represents a real world usage scenario. Exercising the debuggee in -Xcomp mode > is useful IMHO. Yeah. All the SA tests get run in -Xcomp mode in the higher tiers. Maybe we should revisit this. But need to consider that it's rare for SA tests to internally force the debuggee into -Xcomp mode. So if we did not do the -Xcomp runs in the upper tiers, we would not get much testing of debuggees in -Xcomp mode. BTW, this test has always made the debuggee run both with and w/o -Xcomp. But at some point work was done to make LingeredApp use the same JVM options as were given to the test itself. So that means if we did not exclude running this test in -Xcomp mode, we would not really need to force it to have Xcomp test cases. We would just have core and process test cases, and let the tier decide if everything is -Xcomp (debuggee, test, clhsdb), or nothing is. ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From zgu at openjdk.java.net Wed Feb 23 03:07:51 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 23 Feb 2022 03:07:51 GMT Subject: RFR: 8281615: Deadlock caused by jdwp agent [v4] In-Reply-To: <1EzTeqnEJSS5e0tKSNmMCG20cKbiTxoim49wJ_DvyKM=.c3501117-7681-4544-80f2-a9142c5282b2@github.com> References: <1EzTeqnEJSS5e0tKSNmMCG20cKbiTxoim49wJ_DvyKM=.c3501117-7681-4544-80f2-a9142c5282b2@github.com> Message-ID: On Tue, 22 Feb 2022 21:32:05 GMT, David Holmes wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify classTrack_reset and revert bagSize check > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 91: > >> 89: * >> 90: * Note: jvmtiAllocate/jvmtiDeallocate() may be blocked by ongoing safepoints. >> 91: * It is dangerous to call them (via bagCreateBag/bagDestroyBag())while holding monitor(s), > > Nit: need space after )) Fixed. Thanks, @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From zgu at openjdk.java.net Wed Feb 23 03:07:52 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 23 Feb 2022 03:07:52 GMT Subject: Integrated: 8281615: Deadlock caused by jdwp agent In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 14:27:45 GMT, Zhengyu Gu wrote: > There are scenarios that JDWP agent can deadlock on `classTrackLock` monitor. Following is the scenario in bug report. > > **Java Thread** > - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event > - JDWP event callback handler calls `classTrack_processUnloads()` to handle the event. > - `classTrack_processUnloads()` takes `classTrackLock` lock, then tries to allocate a new bag under the lock. > - bag allocation code calls` jvmtiAllocate()`, which may be blocked by ongoing safepoint due to state transition. > > If the safepoint is GC safepoint (prior to JDK16) or `VM_JvmtiPostObjectFree` safepoint (JDK16 or later) > > **VM Thread** > - post `JVMTI_EVENT_OBJECT_FREE` > - JDWP event callback handler calls `cbTrackingObjectFree()` to handle the event > - `cbTrackingObjectFree()` tries to acquire `classTrackLock` lock, leads to deadlock > > From my research, there are three events that may be posted at safepoints, `JVMTI_EVENT_GARBAGE_COLLECTION_START`, `JVMTI_EVENT_GARBAGE_COLLECTION_FINISH` and `JVMTI_EVENT_OBJECT_FREE`, but only `JVMTI_EVENT_OBJECT_FREE` is relevant to JDWP agent. > > The solution I purpose here, is simply move allocation/deallocation code outside of `classTrackLock` lock. > > > Test: > - [x] tier1 > - [x] vmTestbase_nsk_jdi > - [x] vmTestbase_nsk_jdwp > - [x] vmTestbase_nsk_jvmti This pull request has now been integrated. Changeset: e1060bee Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/e1060bee2adb9f2e07ca09309d0f89132db30f28 Stats: 31 lines in 1 file changed: 18 ins; 5 del; 8 mod 8281615: Deadlock caused by jdwp agent Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/7461 From cjplummer at openjdk.java.net Wed Feb 23 05:56:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 23 Feb 2022 05:56:18 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr [v2] In-Reply-To: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: > This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: > > ` * @requires vm.opt.DeoptimizeALot != true` > > When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Move @requires for Xcomp to the correct test case. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7542/files - new: https://git.openjdk.java.net/jdk/pull/7542/files/11719d4f..6edf44a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7542&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7542&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7542/head:pull/7542 PR: https://git.openjdk.java.net/jdk/pull/7542 From dholmes at openjdk.java.net Wed Feb 23 06:20:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Feb 2022 06:20:55 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr [v2] In-Reply-To: References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Wed, 23 Feb 2022 05:56:18 GMT, Chris Plummer wrote: >> This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: >> >> ` * @requires vm.opt.DeoptimizeALot != true` >> >> When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Move @requires for Xcomp to the correct test case. I can't say I fully understand the application of the settings but at least they all now appear to be consistent. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7542 From shade at openjdk.java.net Wed Feb 23 07:18:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Feb 2022 07:18:50 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 19:54:59 GMT, Chris Plummer wrote: > So you load a class 50 times in separate ClassLoaders, and each load triggers the ClassPrepare event, and each time that happens you set a breakpoint on each of the 1000 methods, meaning a total of 5000 breakpoints. Doing this will eventually trigger calling CollectorPolicy::satisfy_failed_metadata_allocation(). Previous to the [8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) fix, this used to trigger an assert. Am I understanding this properly? Yes. That assert is actually the part of the larger issue: metaspace is full, GC is requested, and VM would probably hang if we allow it to happen, since we cannot easily schedule Full GCs when already at safepoint. ------------- PR: https://git.openjdk.java.net/jdk/pull/7554 From sgehwolf at openjdk.java.net Wed Feb 23 10:23:57 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 23 Feb 2022 10:23:57 GMT Subject: RFR: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition In-Reply-To: <1d39j-TR_yxfWCO3WNNrwJh0QScjlrQsMIYHqdnVhQw=.de810d84-70ab-42ec-8474-1710770bd12b@github.com> References: <0_-AS4joC1SWs7K_0XQPYFloJj7DlPHXOhsP5xPrWT8=.3eded7b8-3338-40ee-bc77-0648ce04f2c9@github.com> <1d39j-TR_yxfWCO3WNNrwJh0QScjlrQsMIYHqdnVhQw=.de810d84-70ab-42ec-8474-1710770bd12b@github.com> Message-ID: On Tue, 22 Feb 2022 12:10:46 GMT, zzambers wrote: >> @zzambers do you plan to backport these changes to the old releases and to the jdk8 where this test started to fail? > > @mrserb, I have just created jdk8 backport yesterday and I will probably do other ones soon. Sorry for the delay. @zzambers the `/backport` command works on a commit, not PR. I.e. go to https://github.com/openjdk/jdk/commit/4c52eb39431c2479b0d140907bdcc0311d30f871 and issue the command there. ------------- PR: https://git.openjdk.java.net/jdk/pull/6652 From kevinw at openjdk.java.net Wed Feb 23 14:15:18 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 23 Feb 2022 14:15:18 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Message-ID: Test fails occasionally due to a port clash. Presumably the port that was returned by Utils.getFreePort(), is no longer free. The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. It should retry with a new port if we fail due to a port in use, for some limited number of attempts. main already has some retry logic, but not working: it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. So... Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. ------------- Commit messages: - Remove tab. - Throw on last retry if port clash persists. - Merge remote-tracking branch 'upstream/master' into 8206187_DefaultAgentFilterTest - 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Changes: https://git.openjdk.java.net/jdk/pull/7589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8206187 Stats: 73 lines in 1 file changed: 25 ins; 29 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7589/head:pull/7589 PR: https://git.openjdk.java.net/jdk/pull/7589 From duke at openjdk.java.net Wed Feb 23 15:31:36 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 15:31:36 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v2] In-Reply-To: References: Message-ID: <2an2VYo7_ZVP5AuI8q0thE4undL8ejH-EBwf8x9flbc=.6e0418c6-89ab-4b2e-a511-33ac68a44a47@github.com> > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add changes by David Holmes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7559/files - new: https://git.openjdk.java.net/jdk/pull/7559/files/8364d4b0..9f701eb0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=00-01 Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7559/head:pull/7559 PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Wed Feb 23 15:31:37 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 15:31:37 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. I've updated it. Thanks again. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From amenkov at openjdk.java.net Wed Feb 23 15:41:00 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Feb 2022 15:41:00 GMT Subject: RFR: 8282076: Merge some debug agent changes from the loom repo In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:32:14 GMT, Chris Plummer wrote: > There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. > > The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. > > In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. > > ### Tests: > - [x] vmTestbase/nsk/jdb > - [x] vmTestbase/nsk/jdi > - [x] vmTestbase/nsk/jdwp > - [x] serviceability/jdwp > - [x] jdk/com/sun/jdi Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7524 From duke at openjdk.java.net Wed Feb 23 15:52:31 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 15:52:31 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v3] In-Reply-To: References: Message-ID: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Johannes Bechberger 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: Add changes by David Holmes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7559/files - new: https://git.openjdk.java.net/jdk/pull/7559/files/9f701eb0..ca295d34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7559/head:pull/7559 PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Wed Feb 23 15:54:59 2022 From: duke at openjdk.java.net (zzambers) Date: Wed, 23 Feb 2022 15:54:59 GMT Subject: RFR: 8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition In-Reply-To: References: <0_-AS4joC1SWs7K_0XQPYFloJj7DlPHXOhsP5xPrWT8=.3eded7b8-3338-40ee-bc77-0648ce04f2c9@github.com> <1d39j-TR_yxfWCO3WNNrwJh0QScjlrQsMIYHqdnVhQw=.de810d84-70ab-42ec-8474-1710770bd12b@github.com> Message-ID: On Wed, 23 Feb 2022 10:21:03 GMT, Severin Gehwolf wrote: >> @mrserb, I have just created jdk8 backport yesterday and I will probably do other ones soon. Sorry for the delay. > > @zzambers the `/backport` command works on a commit, not PR. I.e. go to https://github.com/openjdk/jdk/commit/4c52eb39431c2479b0d140907bdcc0311d30f871 and issue the command there. @jerboaa thanks, I was wandering why id did not work. But turned out, that I don't have required role for that anyway, so I did it manual way. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6652 From duke at openjdk.java.net Wed Feb 23 15:56:52 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 15:56:52 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 15:52:31 GMT, Johannes Bechberger wrote: >> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. > > Johannes Bechberger 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: > > Add changes by David Holmes I ran my original tests and found no crashes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From lmesnik at openjdk.java.net Wed Feb 23 16:14:53 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 23 Feb 2022 16:14:53 GMT Subject: RFR: 8282076: Merge some debug agent changes from the loom repo In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:32:14 GMT, Chris Plummer wrote: > There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. > > The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. > > In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. > > ### Tests: > - [x] vmTestbase/nsk/jdb > - [x] vmTestbase/nsk/jdi > - [x] vmTestbase/nsk/jdwp > - [x] serviceability/jdwp > - [x] jdk/com/sun/jdi please update copyrights in the src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7524 From dcubed at openjdk.java.net Wed Feb 23 16:43:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Feb 2022 16:43:53 GMT Subject: RFR: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr [v2] In-Reply-To: References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Wed, 23 Feb 2022 05:56:18 GMT, Chris Plummer wrote: >> This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: >> >> ` * @requires vm.opt.DeoptimizeALot != true` >> >> When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Move @requires for Xcomp to the correct test case. Still thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7542 From cjplummer at openjdk.java.net Wed Feb 23 16:48:29 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 23 Feb 2022 16:48:29 GMT Subject: RFR: 8282076: Merge some debug agent changes from the loom repo [v2] In-Reply-To: References: Message-ID: > There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. > > The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. > > In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. > > ### Tests: > - [x] vmTestbase/nsk/jdb > - [x] vmTestbase/nsk/jdi > - [x] vmTestbase/nsk/jdwp > - [x] serviceability/jdwp > - [x] jdk/com/sun/jdi Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7524/files - new: https://git.openjdk.java.net/jdk/pull/7524/files/623d838b..52c614f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7524&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7524&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7524/head:pull/7524 PR: https://git.openjdk.java.net/jdk/pull/7524 From msheppar at openjdk.java.net Wed Feb 23 17:22:49 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Wed, 23 Feb 2022 17:22:49 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 13:59:19 GMT, Kevin Walls wrote: > Test fails occasionally due to a port clash. > Presumably the port that was returned by Utils.getFreePort(), is no longer free. > The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. > It should retry with a new port if we fail due to a port in use, for some limited number of attempts. > > main already has some retry logic, but not working: > it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). > TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. > Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. > > So... > > Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. > Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. This is reasonable approach to take and should ameliorate the BindException failure condition. But, as it is using the same port allocation strategy which is in current use, then it will be still be suspect to intermittent BindException failures. This will be especially true, as with the current failures, there is a lot of network testing activity with concurrent network test execution and the MACH5 test framework itself e.g. logstash etc. An alternative is to use a fixed port 1098, which previously was the default for RMI Activation daemon. This is now available as activation has been removed from the java platform in JDK17. ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From amenkov at openjdk.java.net Wed Feb 23 17:45:53 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Feb 2022 17:45:53 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use In-Reply-To: References: Message-ID: <_KkuygOYarPELAzDh2OC8TelGKgMzjg-llUkCQIxeDk=.7031205c-a4e5-489a-b879-04953fd133a4@github.com> On Wed, 23 Feb 2022 13:59:19 GMT, Kevin Walls wrote: > Test fails occasionally due to a port clash. > Presumably the port that was returned by Utils.getFreePort(), is no longer free. > The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. > It should retry with a new port if we fail due to a port in use, for some limited number of attempts. > > main already has some retry logic, but not working: > it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). > TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. > Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. > > So... > > Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. > Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. The test uses warm-up predicate in a strange way - it returns true for any output from child process. The main purpose of the predicate is to wait until some expected output is produced, and return false to skip other lines (for example in some environments VM may print some warnings). For this test it may be "main enter" (printed from TestApp.main()). To handle "port in use" error the predicate can search for "bindexception" or "port already in use" line. I don't think check for "exception" and "error" makes much sense here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From dholmes at openjdk.java.net Wed Feb 23 20:23:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Feb 2022 20:23:49 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 15:52:31 GMT, Johannes Bechberger wrote: >> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. > > Johannes Bechberger 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: > > Add changes by David Holmes Hi Johannes, Your original changes need removing again. Thanks, David src/hotspot/share/runtime/thread.hpp line 1325: > 1323: // external JNI entry points where the JNIEnv is passed into the VM. > 1324: // Does not return null, check is_thread_from_jni_environment_termminated() > 1325: // if you are not sure that it is not. Needs deleting. src/hotspot/share/runtime/thread.hpp line 1354: > 1352: return current->is_terminated(); > 1353: } > 1354: Needs deleting. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7559 From cjplummer at openjdk.java.net Wed Feb 23 21:12:55 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 23 Feb 2022 21:12:55 GMT Subject: Integrated: 8282076: Merge some debug agent changes from the loom repo In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:32:14 GMT, Chris Plummer wrote: > There are some minor debug agent changes in the loom repo that are not virtual thread specific, and I would like to merge them into the jdk repo. This will make the future real merge of loom into jdk a bit cleaner. > > The biggest change is moving some code into the new filterAndHandleEvent() function. However, there are no logic changes. It's the same code, just moved into its own function. > > In handleMethodEnterEvent() I reworked some confusing logic and also the comment that goes with it, but it should be functionally the same. > > ### Tests: > - [x] vmTestbase/nsk/jdb > - [x] vmTestbase/nsk/jdi > - [x] vmTestbase/nsk/jdwp > - [x] serviceability/jdwp > - [x] jdk/com/sun/jdi This pull request has now been integrated. Changeset: 253cf785 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/253cf7852f60ecf92e6d675ae2469e5f27425609 Stats: 117 lines in 3 files changed: 61 ins; 45 del; 11 mod 8282076: Merge some debug agent changes from the loom repo Reviewed-by: amenkov, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7524 From duke at openjdk.java.net Wed Feb 23 21:51:46 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 21:51:46 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v3] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 20:18:45 GMT, David Holmes wrote: >> Johannes Bechberger 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: >> >> Add changes by David Holmes > > src/hotspot/share/runtime/thread.hpp line 1354: > >> 1352: return current->is_terminated(); >> 1353: } >> 1354: > > Needs deleting. Of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From duke at openjdk.java.net Wed Feb 23 21:59:35 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 23 Feb 2022 21:59:35 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v4] In-Reply-To: References: Message-ID: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove old code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7559/files - new: https://git.openjdk.java.net/jdk/pull/7559/files/ca295d34..b5bd5f6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7559&range=02-03 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7559/head:pull/7559 PR: https://git.openjdk.java.net/jdk/pull/7559 From dholmes at openjdk.java.net Wed Feb 23 22:04:03 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Feb 2022 22:04:03 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 21:59:35 GMT, Johannes Bechberger wrote: >> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove old code Looks good to me (but I am biased :) )! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7559 From cjplummer at openjdk.java.net Wed Feb 23 22:59:07 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 23 Feb 2022 22:59:07 GMT Subject: Integrated: 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr In-Reply-To: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> References: <97DMLwZ62MRWDzJHj0d296qHQEZe1mpyNmZI77Rgs9c=.eb51d696-e014-41a8-a558-370349ef735e@github.com> Message-ID: On Sat, 19 Feb 2022 04:00:30 GMT, Chris Plummer wrote: > This test has 4 test cases/modes: two core files test cases and two process. Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to run when `-XX:+DeoptimizeALot` is used, because the test does some checks that assume certain methods will be compiled. This is handled by adding the following to the test case: > > ` * @requires vm.opt.DeoptimizeALot != true` > > When this was first added, only the process test cases existed. Later on the core tests cases were added, and the `@requires` was copied improperly. It ended up with `#no-xcomp-process` rather than `#xcomp-core`, which allows the `#xcomp-core` test case to run even when `-XX:+DeoptimizeALot` is being used. This pull request has now been integrated. Changeset: a6610031 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/a6610031e2816156fa14876457e260282a88d478 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod 8281614: serviceability/sa/ClhsdbFindPC.java fails with java.lang.RuntimeException: 'In code in NMethod for jdk/test/lib/apps/LingeredApp.steadyState' missing from stdout/stderr Reviewed-by: dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7542 From mdoerr at openjdk.java.net Thu Feb 24 09:32:12 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 24 Feb 2022 09:32:12 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 21:59:35 GMT, Johannes Bechberger wrote: >> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove old code LGTM. src/hotspot/share/prims/forte.cpp line 565: > 563: JNIEXPORT > 564: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { > 565: Feel free to remove the extra newline. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7559 From kevinw at openjdk.java.net Thu Feb 24 10:10:06 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 10:10:06 GMT Subject: RFR: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 21:59:35 GMT, Johannes Bechberger wrote: >> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove old code Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From kevinw at openjdk.java.net Thu Feb 24 10:33:05 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 10:33:05 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:19:16 GMT, Mark Sheppard wrote: > An alternative is to use a fixed port 1098 Thanks Mark - I will avoid that fixed slot as we no doubt run tests concurrently, and also in case these get backported far enough that it's not free. 8-) Utils.getFreePort() lets new ServerSocket choose a port, but there's clearly a race to use it. We could make it simply random, but I think we need still need to retry like this to avoid failures -- will monitor and see how the race goes with 10 attempts. ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From kevinw at openjdk.java.net Thu Feb 24 11:40:03 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 11:40:03 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use In-Reply-To: <_KkuygOYarPELAzDh2OC8TelGKgMzjg-llUkCQIxeDk=.7031205c-a4e5-489a-b879-04953fd133a4@github.com> References: <_KkuygOYarPELAzDh2OC8TelGKgMzjg-llUkCQIxeDk=.7031205c-a4e5-489a-b879-04953fd133a4@github.com> Message-ID: On Wed, 23 Feb 2022 17:42:35 GMT, Alex Menkov wrote: > The test uses warm-up predicate in a strange way Thanks Alex - yes so that's why we only see one line in the predicate, it contains the word "exception" and the predicate returns true, signalling that the process is done starting up. 8-) But if you do see an exception, you're never going to see the text from the app that it has started OK, so I see why it was returning true always - we were either seeing an error, or otherwise we presume TestApp has started. But it returned true after seeing the first line, which does not contain "bindexception", so it never saw the BindException later to recognise the port being in use. Anyway... I will update shortly to hopefully clarify the predicate part. Still good to keep main() simpler and not have duplicated retry logic there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From kevinw at openjdk.java.net Thu Feb 24 12:17:54 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 12:17:54 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v2] In-Reply-To: References: Message-ID: > Test fails occasionally due to a port clash. > Presumably the port that was returned by Utils.getFreePort(), is no longer free. > The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. > It should retry with a new port if we fail due to a port in use, for some limited number of attempts. > > main already has some retry logic, but not working: > it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). > TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. > Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. > > So... > > Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. > Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Clarify predicate usage. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7589/files - new: https://git.openjdk.java.net/jdk/pull/7589/files/a1bc3d0e..6cdcde8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7589&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7589&range=00-01 Stats: 10 lines in 1 file changed: 4 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7589/head:pull/7589 PR: https://git.openjdk.java.net/jdk/pull/7589 From msheppar at openjdk.java.net Thu Feb 24 12:49:04 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 24 Feb 2022 12:49:04 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v2] In-Reply-To: References: Message-ID: <4mGs7EgpTyMNS9IK-IVWUVvCiAuos9LEgggOngjqFvM=.fa120324-1ce7-4094-af5b-52974a0d20db@github.com> On Thu, 24 Feb 2022 12:17:54 GMT, Kevin Walls wrote: >> Test fails occasionally due to a port clash. >> Presumably the port that was returned by Utils.getFreePort(), is no longer free. >> The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. >> It should retry with a new port if we fail due to a port in use, for some limited number of attempts. >> >> main already has some retry logic, but not working: >> it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). >> TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. >> Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. >> >> So... >> >> Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. >> Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify predicate usage. Marked as reviewed by msheppar (Reviewer). test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 174: > 172: private static final int FREE_PORT_ATTEMPTS = 10; > 173: > 174: private static void testDefaultAgent(String propertyFile) throws Exception { This is a good refactoring change as it also removes some broken logic in the current retry strategy ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From amenkov at openjdk.java.net Thu Feb 24 13:14:10 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 24 Feb 2022 13:14:10 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 12:17:54 GMT, Kevin Walls wrote: >> Test fails occasionally due to a port clash. >> Presumably the port that was returned by Utils.getFreePort(), is no longer free. >> The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. >> It should retry with a new port if we fail due to a port in use, for some limited number of attempts. >> >> main already has some retry logic, but not working: >> it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). >> TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. >> Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. >> >> So... >> >> Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. >> Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify predicate usage. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From amenkov at openjdk.java.net Thu Feb 24 13:28:25 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 24 Feb 2022 13:28:25 GMT Subject: RFR: 8267796: vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java fails with NoClassDefFoundError Message-ID: The fix adds workaround in hs201t001a class like we have in hs201t001 test to avoid class loading while the test do single stepping/pop frame. Also fixed a number of issues in the test. ------------- Commit messages: - trailing whitespace - JDK-8267796 Changes: https://git.openjdk.java.net/jdk/pull/7607/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7607&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267796 Stats: 125 lines in 4 files changed: 55 ins; 37 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/7607.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7607/head:pull/7607 PR: https://git.openjdk.java.net/jdk/pull/7607 From amenkov at openjdk.java.net Thu Feb 24 13:28:33 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 24 Feb 2022 13:28:33 GMT Subject: RFR: 8267796: vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 12:44:18 GMT, Alex Menkov wrote: > The fix adds workaround in hs201t001a class like we have in hs201t001 test to avoid class loading while the test do single stepping/pop frame. > Also fixed a number of issues in the test. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java line 74: > 72: * > 73: * @run main/othervm/native > 74: * -agentlib:hs201t002=pathToNewByteCode=./bin,-waittime=5,-verbose Adds verbose output for the test and agent test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 48: > 46: > 47: static jint testStep; > 48: static int redefineNumber; not used test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 127: > 125: nsk_jvmti_setFailStatus(); > 126: } > 127: if (!NSK_JVMTI_VERIFY(jvmti_env->Deallocate(newClassBytes))) { proper resource deallocation test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 334: > 332: jclass klass; > 333: > 334: NSK_DISPLAY2("\n\n>>>> Exception %s in thread - %s\n", getClassName() and getThreadName() used the same global buffer to return results. So thread name overrides class name and in log we see: >>>> Exception hs201t002Thread in thread - hs201t002Thread instead of >>>> Exception Lnsk/jvmti/scenarios/hotswap/HS201/hs201t002a; in thread - hs201t002Thread test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 382: > 380: /* ============================================================================= */ > 381: > 382: int readNewBytecode(jvmtiEnv* jvmti, jint &newClassSize, unsigned char* &newClassBytes) { The function returns loaded data instead of using global variable for correct resource management test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 429: > 427: /* ============================================================================= */ > 428: > 429: const char* getThreadName(jvmtiEnv* jvmti_env, JNIEnv* jni_env, jthread thread) { The function now returns JVMTI allocated buffer instead of global buffer test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 468: > 466: /* ============================================================================= */ > 467: > 468: const char* getClassName(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jobject object) { The function now returns JVMTI allocated buffer instead of global buffer test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 668: > 666: NSK_DISPLAY0("Enable events\n"); > 667: > 668: enableEvent(jvmti, JVMTI_EVENT_CLASS_LOAD, testedThread); This code executed on agent initialization, the test has no chance to set testThread. Moved to hs201t002.setThread() test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java line 29: > 27: > 28: public hs201t002a () { > 29: System.out.println("Current step: " + hs201t002.currentStep); // Avoid calling classloader to find hs201t002 in doInit() This is the fix for the failure, the rest are test improvements ------------- PR: https://git.openjdk.java.net/jdk/pull/7607 From duke at openjdk.java.net Thu Feb 24 14:36:05 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 24 Feb 2022 14:36:05 GMT Subject: Integrated: 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger wrote: > Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the newly introduced method `JavaThread::thread_from_jni_environment`. This pull request has now been integrated. Changeset: 231e48fa Author: Johannes Bechberger Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/231e48fa63aeb4e35c7c948f958695d62b7157ce Stats: 9 lines in 2 files changed: 3 ins; 3 del; 3 mod 8282200: ShouldNotReachHere() reached by AsyncGetCallTrace after JDK-8280422 Reviewed-by: dholmes, mdoerr, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/7559 From kevinw at openjdk.java.net Thu Feb 24 15:02:40 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 15:02:40 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v3] In-Reply-To: References: Message-ID: > Test fails occasionally due to a port clash. > Presumably the port that was returned by Utils.getFreePort(), is no longer free. > The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. > It should retry with a new port if we fail due to a port in use, for some limited number of attempts. > > main already has some retry logic, but not working: > it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). > TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. > Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. > > So... > > Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. > Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: break to terminate retry loop when succesful ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7589/files - new: https://git.openjdk.java.net/jdk/pull/7589/files/6cdcde8a..33649830 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7589&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7589&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7589/head:pull/7589 PR: https://git.openjdk.java.net/jdk/pull/7589 From kevinw at openjdk.java.net Thu Feb 24 15:02:42 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 24 Feb 2022 15:02:42 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v2] In-Reply-To: References: Message-ID: <2wuW-h6ZQ4qTmPhHo89cfvY64q8jrWjUI0MQMPZGy8Y=.cd822605-743b-4d42-b4b5-fdc9d2491c2c@github.com> On Thu, 24 Feb 2022 12:17:54 GMT, Kevin Walls wrote: >> Test fails occasionally due to a port clash. >> Presumably the port that was returned by Utils.getFreePort(), is no longer free. >> The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. >> It should retry with a new port if we fail due to a port in use, for some limited number of attempts. >> >> main already has some retry logic, but not working: >> it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). >> TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. >> Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. >> >> So... >> >> Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. >> Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify predicate usage. Thanks for the reviews! Apologies, one more update - I had a break in there earlier to terminate the retry loop, and I removed it accidentally when changing things to make it fail. The retry loop has to let the testDefaultAgent method complete normally (which needs the break), or by throwing an Exception. Both looking good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From msheppar at openjdk.java.net Thu Feb 24 23:40:12 2022 From: msheppar at openjdk.java.net (Mark Sheppard) Date: Thu, 24 Feb 2022 23:40:12 GMT Subject: RFR: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use [v3] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 15:02:40 GMT, Kevin Walls wrote: >> Test fails occasionally due to a port clash. >> Presumably the port that was returned by Utils.getFreePort(), is no longer free. >> The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. >> It should retry with a new port if we fail due to a port in use, for some limited number of attempts. >> >> main already has some retry logic, but not working: >> it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). >> TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. >> Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. >> >> So... >> >> Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. >> Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > break to terminate retry loop when succesful Marked as reviewed by msheppar (Reviewer). A good spot by yourself ... as the focus was on the BindException correction and the pass condition is an Exception being thrown, it was easy to miss the break for a failure condition ... a similar issue existed in the current test albeit only if an InvocationTargetException with a nested BindException was thrown and the retry resulted in the InvalidClassException or UnmarcshalledException !! ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From kevinw at openjdk.java.net Fri Feb 25 08:00:02 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 25 Feb 2022 08:00:02 GMT Subject: Integrated: 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 13:59:19 GMT, Kevin Walls wrote: > Test fails occasionally due to a port clash. > Presumably the port that was returned by Utils.getFreePort(), is no longer free. > The test creates a ProcessBuilder with the parameters for JMX, including port number, and uses that to create a new Process. > It should retry with a new port if we fail due to a port in use, for some limited number of attempts. > > main already has some retry logic, but not working: > it checks for an InvocationTargetException to contain a BindException, but it simply gets a BindException, thrown by TestAppRun.start(). > TestAppRun.start() runs the new process and scans for errors, but on failure its predicate has only seen the first line of a failure, so a BindException is never recognised and thrown. > Also main does not limit the retries, and handling the port retry in main() is duplicated, for each run of the test method. > > So... > > Make the error-scanning predicate in TestAppRun recognise a "port in use" message and throw a BindExeption. This is a notification to the caller that it failed, it's not the actual BindException as that was thrown in a different process. > Make the testDefaultAgent method (the main part of the test) handle retrying with a new port, a limited number of times. This pull request has now been integrated. Changeset: cd36be42 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/cd36be42c2eb3eacdb3625e87510eb15acac3230 Stats: 82 lines in 1 file changed: 30 ins; 30 del; 22 mod 8206187: javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java fails with Port already in use Reviewed-by: msheppar, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/7589 From mikael at openjdk.java.net Sun Feb 27 03:49:12 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sun, 27 Feb 2022 03:49:12 GMT Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java In-Reply-To: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> Message-ID: On Sun, 27 Feb 2022 03:37:11 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7631 From dcubed at openjdk.java.net Sun Feb 27 03:49:12 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 27 Feb 2022 03:49:12 GMT Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java Message-ID: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java. ------------- Commit messages: - 8282428: ProblemList jdk/jfr/jvm/TestWaste.java Changes: https://git.openjdk.java.net/jdk/pull/7631/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282428 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7631/head:pull/7631 PR: https://git.openjdk.java.net/jdk/pull/7631 From dcubed at openjdk.java.net Sun Feb 27 03:49:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 27 Feb 2022 03:49:14 GMT Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java In-Reply-To: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> Message-ID: On Sun, 27 Feb 2022 03:37:11 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java. This pull request has now been integrated. Changeset: 630ad1ac Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/630ad1acb20abae8bde037b8d23dd2a14a70d732 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8282428: ProblemList jdk/jfr/jvm/TestWaste.java Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/7631 From dcubed at openjdk.java.net Sun Feb 27 03:49:13 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 27 Feb 2022 03:49:13 GMT Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java In-Reply-To: References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com> Message-ID: On Sun, 27 Feb 2022 03:42:50 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! Especially considering that it's Saturday night... ------------- PR: https://git.openjdk.java.net/jdk/pull/7631 From shade at openjdk.java.net Mon Feb 28 15:51:24 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 28 Feb 2022 15:51:24 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v2] In-Reply-To: References: Message-ID: <1RZWpYktaVz2GTABs1Mymh2dNf30EBq0RImVWH_Ncfw=.e5ec00e7-19b2-4024-814e-79b5e8302864@github.com> > There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. > > Requires [JDK-8282172](https://bugs.openjdk.java.net/browse/JDK-8282172) to pass cleanly in fastdebug mode. > > Additional testing: > - [x] New test on Linux x86_64 fastdebug > - [x] New test on Linux x86_64 release > - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8282170-jvmti-setbreakpoint-test - Merge branch 'master' into JDK-8282170-jvmti-setbreakpoint-test - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7554/files - new: https://git.openjdk.java.net/jdk/pull/7554/files/5ffee594..4edd20df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7554&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7554&range=00-01 Stats: 11653 lines in 264 files changed: 8362 ins; 1419 del; 1872 mod Patch: https://git.openjdk.java.net/jdk/pull/7554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7554/head:pull/7554 PR: https://git.openjdk.java.net/jdk/pull/7554 From cjplummer at openjdk.java.net Mon Feb 28 18:31:13 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 28 Feb 2022 18:31:13 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v2] In-Reply-To: <1RZWpYktaVz2GTABs1Mymh2dNf30EBq0RImVWH_Ncfw=.e5ec00e7-19b2-4024-814e-79b5e8302864@github.com> References: <1RZWpYktaVz2GTABs1Mymh2dNf30EBq0RImVWH_Ncfw=.e5ec00e7-19b2-4024-814e-79b5e8302864@github.com> Message-ID: On Mon, 28 Feb 2022 15:51:24 GMT, Aleksey Shipilev wrote: >> There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. >> >> Requires [JDK-8282172](https://bugs.openjdk.java.net/browse/JDK-8282172) to pass cleanly in fastdebug mode. >> >> Additional testing: >> - [x] New test on Linux x86_64 fastdebug >> - [x] New test on Linux x86_64 release >> - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8282170-jvmti-setbreakpoint-test > - Merge branch 'master' into JDK-8282170-jvmti-setbreakpoint-test > - Fix test/hotspot/jtreg/serviceability/jvmti/SetBreakpoint/TestManyBreakpoints.java line 2: > 1: /* > 2: * Copyright (c) 2013, 2022, Oracle and/or its affiliates. All rights reserved. Unless you copied a substantial part of this test, I don't think the 2013 copyright is necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7554 From shade at openjdk.java.net Mon Feb 28 18:49:05 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 28 Feb 2022 18:49:05 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v3] In-Reply-To: References: Message-ID: > There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. > > Requires [JDK-8282172](https://bugs.openjdk.java.net/browse/JDK-8282172) to pass cleanly in fastdebug mode. > > Additional testing: > - [x] New test on Linux x86_64 fastdebug > - [x] New test on Linux x86_64 release > - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7554/files - new: https://git.openjdk.java.net/jdk/pull/7554/files/4edd20df..2df7af3b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7554&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7554&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7554/head:pull/7554 PR: https://git.openjdk.java.net/jdk/pull/7554 From shade at openjdk.java.net Mon Feb 28 18:49:05 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 28 Feb 2022 18:49:05 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v3] In-Reply-To: References: <1RZWpYktaVz2GTABs1Mymh2dNf30EBq0RImVWH_Ncfw=.e5ec00e7-19b2-4024-814e-79b5e8302864@github.com> Message-ID: On Tue, 22 Feb 2022 19:43:46 GMT, Chris Plummer wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright > > test/hotspot/jtreg/serviceability/jvmti/SetBreakpoint/TestManyBreakpoints.java line 2: > >> 1: /* >> 2: * Copyright (c) 2013, 2022, Oracle and/or its affiliates. All rights reserved. > > Unless you copied a substantial part of this test, I don't think the 2013 copyright is necessary. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7554 From cjplummer at openjdk.java.net Mon Feb 28 19:05:17 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 28 Feb 2022 19:05:17 GMT Subject: RFR: 8282170: JVMTI SetBreakpoint metaspace allocation test [v3] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 18:49:05 GMT, Aleksey Shipilev wrote: >> There are few bugs in SetBreakpoint when it reaches for metaspace allocation, notably [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This adds the test that exercises the metaspace allocation paths. >> >> Requires [JDK-8282172](https://bugs.openjdk.java.net/browse/JDK-8282172) to pass cleanly in fastdebug mode. >> >> Additional testing: >> - [x] New test on Linux x86_64 fastdebug >> - [x] New test on Linux x86_64 release >> - [x] New test with [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149) reverted fails on Linux x86_64 release > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7554 From cjplummer at openjdk.java.net Mon Feb 28 19:14:25 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 28 Feb 2022 19:14:25 GMT Subject: RFR: 8267796: vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 12:44:18 GMT, Alex Menkov wrote: > The fix adds workaround in hs201t001a class like we have in hs201t001 test to avoid class loading while the test do single stepping/pop frame. > Also fixed a number of issues in the test. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002.java line 84: > 82: thread.start(); > 83: > 84: // enable events requires live thread I think a more detailed comment could be used here. Something like: // setThread(thread) enables JVMTI events, and that can only be done on a live thread, // so wait until the thread has started. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 107: > 105: } > 106: > 107: if (!NSK_VERIFY(readNewBytecode(jvmti_env, newClassSize, newClassBytes))) { For simple types I don't care for C++ pass-by-ref arguments. At the call site it just looks like the values are being passed in. When I first read this it didn't look right to me since they are uninitialized, so I had to look at readNewBytecode() to see what was going on. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp line 368: > 366: if (threadName != NULL) { > 367: jvmti->Deallocate((unsigned char*)threadName); > 368: } callbackException() and callbackExceptionCatch() seem to be identical other than callbackException() taking a couple of extra unused arguments. They should probably both just call a shared function. ------------- PR: https://git.openjdk.java.net/jdk/pull/7607