From dcubed at openjdk.java.net Sat May 1 00:19:39 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 1 May 2021 00:19:39 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary "@library /test/lib". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/3b4004d8..bac63a79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From whuang at openjdk.java.net Sat May 1 04:15:14 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 1 May 2021 04:15:14 GMT Subject: RFR: 8266187: Memory leak in appendBootClassPath() [v2] In-Reply-To: References: Message-ID: > Dear All, > I find a memory leak in `appendBootClassPath()` > https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950 > * we malloc `resolved` from resolve(parent, path) > * we use `resolved` in line 951 > * we don't free() this memory after using. > > I think we can fix this bug by adding a free() after line 951 as my commit. > Thank you for your review. Any suggestion is welcome. > > Yours , > Wang Huang Wang Huang has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3751/files - new: https://git.openjdk.java.net/jdk/pull/3751/files/c973192e..c2899578 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3751&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3751&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3751.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3751/head:pull/3751 PR: https://git.openjdk.java.net/jdk/pull/3751 From whuang at openjdk.java.net Sat May 1 04:15:14 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 1 May 2021 04:15:14 GMT Subject: RFR: 8266187: Memory leak in appendBootClassPath() In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 10:17:42 GMT, Kevin Walls wrote: > Oops - please update the copyright year, thanks! (second year in the header is currently 2019, should become 2021). Thank you for your suggestion. I have update that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3751 From github.com+3094961+buddyliao at openjdk.java.net Sat May 1 11:37:08 2021 From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao) Date: Sat, 1 May 2021 11:37:08 GMT Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods Message-ID: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. ------------- Commit messages: - 8266193: BasicJMapTest should include testHistoParallel methods Changes: https://git.openjdk.java.net/jdk/pull/3810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266193 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3810/head:pull/3810 PR: https://git.openjdk.java.net/jdk/pull/3810 From vromero at openjdk.java.net Sun May 2 02:10:26 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 2 May 2021 02:10:26 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04-05 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From david.holmes at oracle.com Sun May 2 05:48:22 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 2 May 2021 15:48:22 +1000 Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> <4VOXQ7X3vPyTIQJQ38PdExpGKj3f_ABeABa2ZDquBSg=.813d4dba-f14e-421f-811e-f2b65420fdaa@github.com> Message-ID: <47438cf3-dc38-f77b-e558-60eb2d7b707c@oracle.com> On 1/05/2021 6:57 am, Daniel D.Daugherty wrote: > On Wed, 28 Apr 2021 12:55:18 GMT, David Holmes wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 137: >> >>> 135: } >>> 136: >>> 137: System.exit(run(timeMax, System.out) + exit_delta); >> >> jtreg tests don't use System.exit! > > Hmmm... that's generally true, but this is a test that must be run as > "othervm" so this style of exit with the "+ exit_delta" logic has been > used for these kinds of stress tests. I think this style came from the > VMTestbase tests and I've used it with other stress tests. Hmmm... this is a legacy style/approach that is not necessary any more. If the test fails it should throw an exception from the main thread and that will produce a non-zero exit value. I think seeing this legacy style in new tests will just confuse people. YMMV. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3478 > From github.com+2217224+kariya-mitsuru at openjdk.java.net Sun May 2 16:07:26 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Sun, 2 May 2021 16:07:26 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: > The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. > This PR changes to use `Long.hashCode` instead. Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: Add some more SA's classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3522/files - new: https://git.openjdk.java.net/jdk/pull/3522/files/d1e30f77..ac5c2660 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3522&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3522&range=01-02 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3522/head:pull/3522 PR: https://git.openjdk.java.net/jdk/pull/3522 From github.com+2217224+kariya-mitsuru at openjdk.java.net Sun May 2 16:14:01 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Sun, 2 May 2021 16:14:01 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Add some more SA's classes I found that `WindbgAARCH64Thread` is the same, so I changed it together. ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From github.com+2217224+kariya-mitsuru at openjdk.java.net Sun May 2 16:19:55 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Sun, 2 May 2021 16:19:55 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Add some more SA's classes I have changed the title of this PR but I cannot change the title of issue JDK-8264734. Would it have been better if I hadn't changed the title? ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From ysuenaga at openjdk.java.net Mon May 3 01:43:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 3 May 2021 01:43:53 GMT Subject: RFR: 8265505: findsym does not work on remote debug server [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:18:43 GMT, Yasumasa Suenaga wrote: >> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server. >> >> >> hsdb> verbose true >> hsdb> findsym gHotSpotVMTypes >> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null >> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957) >> 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:282) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493) >> >> >> The cause of this NPE is that CDebugger is null. It happens when the debugger is running on debugd server. >> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme. >> >> This PR has passed serviceability/sa tests on Linux x64. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Ping: Could you review this PR? I need one more reviewer to push. ------------- PR: https://git.openjdk.java.net/jdk/pull/3582 From fmatte at openjdk.java.net Mon May 3 04:17:54 2021 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Mon, 3 May 2021 04:17:54 GMT Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser.typeName()" retruns " double[][]" >> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double" >> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails. >> >> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine. > > Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision: > > - Update ArrayReferenceImpl.java > - Update ArrayTypeImpl.java Hi Chris, thanks for the rreview. > test/hotspot/jtreg/vmTestbase/nsk/jdb > test/hotspot/jtreg/serviceability/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdwp > test/hotspot/jtreg/vmTestbase/nsk/jdi > test/jdk/com/sun/jdi I have verified tier1 to tier8 and didn't find any issues. Could you please sponsor this push for me. Thanks, ------------- PR: https://git.openjdk.java.net/jdk/pull/3658 From github.com+7947546+tanghaoth90 at openjdk.java.net Mon May 3 14:42:59 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Mon, 3 May 2021 14:42:59 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load Message-ID: OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". ------------- Commit messages: - 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load Changes: https://git.openjdk.java.net/jdk/pull/3656/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265836 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From jlahoda at openjdk.java.net Mon May 3 16:41:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 3 May 2021 16:41:54 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From mail.arghac at gmail.com Mon May 3 17:14:07 2021 From: mail.arghac at gmail.com (Argha C) Date: Mon, 3 May 2021 10:14:07 -0700 Subject: OperatingSystemImpl should factor cpu shares when calculating system load Message-ID: Hello, I wanted to report an issue we're seeing with the load calculation, when running with cpu shares > 1, in a container environment. Specifically, the implementation of *OperatingSystemImpl#getCpuLoad.* *Problem* When running with allocation of multiple cpu shares, ie. > 1 unit, the load numbers do not comply with the expected range of 0-1. In the example screenshot, it goes beyond 4. This miscalculation throws off load based system heuristics, when running in a container based environment. *Proposed solution* In a container aware environment, for load average calculation, the number of cpu cycles, ie. *getCpuPeriod *must be multiplied by the number of requested cpu shares by the process, ie. *getCpuShares.* This would ensure that the load calculation uses the correct denominator for elapsed time slice periods. In the screenshot below, this would mean using *getCpuShares *as a multiplier for *periodLength.* Please consider validating this behavior. I'd be happy to submit a PR but I'm not an openjdk author/contributor. Thanks for your consideration. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2021-05-03 at 10.02.27 AM.png Type: image/png Size: 479711 bytes Desc: not available URL: From david.holmes at oracle.com Mon May 3 22:21:35 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 May 2021 08:21:35 +1000 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: References: Message-ID: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> Hi, Is this related to the issue reported here: https://bugs.openjdk.java.net/browse/JDK-8265836 Cheers, David On 4/05/2021 3:14 am, Argha C wrote: > Hello, > I wanted to report an issue we're seeing with the load calculation, when > running with cpu shares > 1, in a container environment. Specifically, > the implementation of /OperatingSystemImpl#getCpuLoad./ > / > / > /Problem/ > / > / > When running with allocation of multiple cpu shares, ie. > 1 unit, the > load numbers do not comply with the expected range of 0-1. In the > example screenshot, it goes beyond 4. > This miscalculation throws off load based system heuristics, when > running in a container based environment. > > /Proposed solution/ > / > / > In a container aware environment, for load average calculation, the > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the > number of requested cpu shares by the process, ie. /getCpuShares./ > This would ensure that the load calculation uses the correct denominator > for elapsed time slice periods. > > In the screenshot below, this would mean using /getCpuShares /as a > multiplier for /periodLength./ > > Please consider validating this behavior. I'd be happy to submit a PR > but I'm not an openjdk author/contributor. > Thanks for your consideration. From mail.arghac at gmail.com Mon May 3 23:07:06 2021 From: mail.arghac at gmail.com (Argha C) Date: Mon, 3 May 2021 16:07:06 -0700 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> References: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> Message-ID: Hello David, It does look quite similar. The crux is factoring in the sum of cpu time across all shares, instead of a single cpu share. My proposal for implementing the fix is slightly different from the PR, but happy to trust your advice on taking this forward. On Mon, May 3, 2021 at 3:21 PM David Holmes wrote: > Hi, > > Is this related to the issue reported here: > > https://bugs.openjdk.java.net/browse/JDK-8265836 > > Cheers, > David > > On 4/05/2021 3:14 am, Argha C wrote: > > Hello, > > I wanted to report an issue we're seeing with the load calculation, when > > running with cpu shares > 1, in a container environment. Specifically, > > the implementation of /OperatingSystemImpl#getCpuLoad./ > > / > > / > > /Problem/ > > / > > / > > When running with allocation of multiple cpu shares, ie. > 1 unit, the > > load numbers do not comply with the expected range of 0-1. In the > > example screenshot, it goes beyond 4. > > This miscalculation throws off load based system heuristics, when > > running in a container based environment. > > > > /Proposed solution/ > > / > > / > > In a container aware environment, for load average calculation, the > > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the > > number of requested cpu shares by the process, ie. /getCpuShares./ > > This would ensure that the load calculation uses the correct denominator > > for elapsed time slice periods. > > > > In the screenshot below, this would mean using /getCpuShares /as a > > multiplier for /periodLength./ > > > > Please consider validating this behavior. I'd be happy to submit a PR > > but I'm not an openjdk author/contributor. > > Thanks for your consideration. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon May 3 23:50:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 May 2021 09:50:24 +1000 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: References: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> Message-ID: <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com> On 4/05/2021 9:07 am, Argha C wrote: > Hello David, > It does look quite similar. > The crux is factoring in the sum of cpu time across all shares, instead > of a single cpu share. > My proposal for implementing the fix is slightly different from the PR, > but happy to trust your advice on taking this forward. I would suggest liaising with the contributors of https://github.com/openjdk/jdk/pull/3656 so see if all of the issues can be addressed together. Cheers, David > > On Mon, May 3, 2021 at 3:21 PM David Holmes > wrote: > > Hi, > > Is this related to the issue reported here: > > https://bugs.openjdk.java.net/browse/JDK-8265836 > > > Cheers, > David > > On 4/05/2021 3:14 am, Argha C wrote: > > Hello, > > I wanted to report an issue we're seeing with the load > calculation, when > > running with cpu shares > 1, in a container environment. > Specifically, > > the implementation of /OperatingSystemImpl#getCpuLoad./ > > / > > / > > /Problem/ > > / > > / > > When running with allocation of multiple cpu shares, ie. > 1 > unit, the > > load numbers do not comply with the expected range of 0-1. In the > > example screenshot, it goes beyond 4. > > This miscalculation throws off load based system heuristics, when > > running in a container based environment. > > > > /Proposed solution/ > > / > > / > > In a container aware environment, for load average calculation, the > > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the > > number of requested cpu shares by the process, ie. /getCpuShares./ > > This would ensure that the load calculation uses the correct > denominator > > for elapsed time slice periods. > > > > In the screenshot below, this would mean using /getCpuShares /as a > > multiplier for /periodLength./ > > > > Please consider validating this behavior. I'd be happy to submit > a PR > > but I'm not an openjdk author/contributor. > > Thanks for your consideration. > From larry.cable at oracle.com Tue May 4 00:57:16 2021 From: larry.cable at oracle.com (Laurence Cable) Date: Mon, 3 May 2021 17:57:16 -0700 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com> References: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com> Message-ID: <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com> On 5/3/21 4:50 PM, David Holmes wrote: > On 4/05/2021 9:07 am, Argha C wrote: >> Hello David, >> It does look quite similar. >> The crux is factoring in the sum of cpu time across all shares, >> instead of a single cpu share. >> My proposal for implementing the fix is slightly different from the >> PR, but happy to trust your advice on taking this forward. > > I would suggest liaising with the contributors of > > https://github.com/openjdk/jdk/pull/3656 > > so see if all of the issues can be addressed together. +1! > > Cheers, > David > >> >> On Mon, May 3, 2021 at 3:21 PM David Holmes > > wrote: >> >> ??? Hi, >> >> ??? Is this related to the issue reported here: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8265836 >> ??? >> >> ??? Cheers, >> ??? David >> >> ??? On 4/05/2021 3:14 am, Argha C wrote: >> ???? > Hello, >> ???? > I wanted to report an issue we're seeing with the load >> ??? calculation, when >> ???? > running with cpu shares > 1, in a container environment. >> ??? Specifically, >> ???? > the implementation of /OperatingSystemImpl#getCpuLoad./ >> ???? > / >> ???? > / >> ???? > /Problem/ >> ???? > / >> ???? > / >> ???? > When running with allocation of multiple cpu shares, ie. > 1 >> ??? unit, the >> ???? > load numbers do not comply with the expected range of 0-1. In the >> ???? > example screenshot, it goes beyond 4. >> ???? > This miscalculation throws off load based system heuristics, when >> ???? > running in a container based environment. >> ???? > >> ???? > /Proposed solution/ >> ???? > / >> ???? > / >> ???? > In a container aware environment, for load average >> calculation, the >> ???? > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by >> the >> ???? > number of requested cpu shares by the process, ie. >> /getCpuShares./ >> ???? > This would ensure that the load calculation uses the correct >> ??? denominator >> ???? > for elapsed time slice periods. >> ???? > >> ???? > In the screenshot below, this would mean using /getCpuShares >> /as a >> ???? > multiplier for /periodLength./ >> ???? > >> ???? > Please consider validating this behavior. I'd be happy to submit >> ??? a PR >> ???? > but I'm not an openjdk author/contributor. >> ???? > Thanks for your consideration. >> -------------- next part -------------- A non-text attachment was scrubbed... Name: larry_cable.vcf Type: text/x-vcard Size: 217 bytes Desc: not available URL: From kevinw at openjdk.java.net Tue May 4 09:37:54 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 4 May 2021 09:37:54 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Add some more SA's classes Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From kevinw at openjdk.java.net Tue May 4 09:40:52 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 4 May 2021 09:40:52 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Add some more SA's classes No problem. I updated the JBS title to match this. I think the warning about title mismatch has gone. ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From kevinw at openjdk.java.net Tue May 4 09:53:01 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 4 May 2021 09:53:01 GMT Subject: RFR: 8265505: findsym does not work on remote debug server [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 23:18:43 GMT, Yasumasa Suenaga wrote: >> We can see following error when we run `findsym` on CLHSDB which connects to remote debug server. >> >> >> hsdb> verbose true >> hsdb> findsym gHotSpotVMTypes >> 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null >> java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086) >> at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957) >> 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:282) >> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493) >> >> >> The cause of this NPE is that CDebugger is null. It happens when the debugger is running on debugd server. >> Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme. >> >> This PR has passed serviceability/sa tests on Linux x64. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Thanks - definitely good to have that Windows symbol logic out of CommandProcessor. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java line 114: > 112: /** > 113: * Find address and executable which contains symbol. > 114: */ Just a whitespace nit - the * doesn't align. 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/3582 From whuang at openjdk.java.net Tue May 4 10:05:06 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 4 May 2021 10:05:06 GMT Subject: Integrated: 8266187: Memory leak in appendBootClassPath() In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 06:38:57 GMT, Wang Huang wrote: > Dear All, > I find a memory leak in `appendBootClassPath()` > https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#L950 > * we malloc `resolved` from resolve(parent, path) > * we use `resolved` in line 951 > * we don't free() this memory after using. > > I think we can fix this bug by adding a free() after line 951 as my commit. > Thank you for your review. Any suggestion is welcome. > > Yours , > Wang Huang This pull request has now been integrated. Changeset: aa90df6f Author: Wang Huang Committer: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8266187: Memory leak in appendBootClassPath() Co-authored-by: Wang Huang Co-authored-by: Sun Jianye Reviewed-by: kevinw, mli, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3751 From ysuenaga at openjdk.java.net Tue May 4 11:47:22 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 4 May 2021 11:47:22 GMT Subject: RFR: 8265505: findsym does not work on remote debug server [v3] In-Reply-To: References: Message-ID: <13GKiD9JQOYJDJhrb5bpI8RzJNlMJlQvbrteqa-WGQg=.c07f9c9b-bd43-4520-b8cb-1ba26d6ad37a@github.com> > We can see following error when we run `findsym` on CLHSDB which connects to remote debug server. > > > hsdb> verbose true > hsdb> findsym gHotSpotVMTypes > 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null > java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957) > 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:282) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493) > > > The cause of this NPE is that CDebugger is null. It happens when the debugger is running on debugd server. > Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme. > > This PR has passed serviceability/sa tests on Linux x64. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Align whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3582/files - new: https://git.openjdk.java.net/jdk/pull/3582/files/6ef93d7d..b65c6fef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3582&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3582&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3582/head:pull/3582 PR: https://git.openjdk.java.net/jdk/pull/3582 From ysuenaga at openjdk.java.net Tue May 4 11:47:23 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 4 May 2021 11:47:23 GMT Subject: RFR: 8265505: findsym does not work on remote debug server [v3] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 09:49:13 GMT, Kevin Walls wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Align whitespace > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java line 114: > >> 112: /** >> 113: * Find address and executable which contains symbol. >> 114: */ > > Just a whitespace nit - the * doesn't align. 8-) Thanks! I aligned whitespace in new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3582 From ysuenaga at openjdk.java.net Tue May 4 12:04:54 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 4 May 2021 12:04:54 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga wrote: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. Ping: Could you review this PR and [CSR](https://bugs.openjdk.java.net/browse/JDK-8265897) ? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Tue May 4 12:05:59 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 4 May 2021 12:05:59 GMT Subject: RFR: 8266038: Move newAddress() to JVMDebugger In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga wrote: > SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class. > > Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`). Ping: Could you review this PR? I need Reviewer(s). ------------- PR: https://git.openjdk.java.net/jdk/pull/3714 From coleenp at openjdk.java.net Tue May 4 12:39:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 4 May 2021 12:39:07 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication Message-ID: Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. Tested with tier1-6, tiers 7,8 are running and 98% passing. ------------- Commit messages: - 8266497: Remove unnecessary EMCP liveness indication Changes: https://git.openjdk.java.net/jdk/pull/3852/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3852&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266497 Stats: 78 lines in 4 files changed: 9 ins; 64 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3852/head:pull/3852 PR: https://git.openjdk.java.net/jdk/pull/3852 From github.com+971473+argha-c at openjdk.java.net Tue May 4 17:01:55 2021 From: github.com+971473+argha-c at openjdk.java.net (Argha C) Date: Tue, 4 May 2021 17:01:55 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang wrote: > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142: > 140: long usageNanos = containerMetrics.getCpuUsage(); > 141: if (numPeriods > 0 && usageNanos > 0) { > 142: long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods); We happened to hit an exactly similar problem when running on a container with openjdk15. Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. Is there a good reason `getCpuQuota` is a better alternative? ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From iklam at openjdk.java.net Tue May 4 18:17:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 4 May 2021 18:17:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Looks reasonable to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Tue May 4 19:24:56 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 4 May 2021 19:24:56 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks Ioi, and thanks for updating the description. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From amenkov at openjdk.java.net Tue May 4 20:33:58 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 4 May 2021 20:33:58 GMT Subject: RFR: 8266038: Move newAddress() to JVMDebugger In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga wrote: > SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class. > > Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`). Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3714 From dholmes at openjdk.java.net Tue May 4 23:55:50 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 23:55:50 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Sorry for the delay in noticing this PR! Fix looks good. One nit on variable naming below. Thanks, David src/hotspot/share/logging/logConfiguration.cpp line 430: > 428: ConfigurationLock cl; > 429: size_t idx; > 430: bool is_added = false; Nit: `was_added` (or even just `added`) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From dholmes at openjdk.java.net Wed May 5 00:19:49 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 5 May 2021 00:19:49 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Hi Coleen, Seems reasonable. Nice simplification too! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From ysuenaga at openjdk.java.net Wed May 5 00:26:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 5 May 2021 00:26:52 GMT Subject: Integrated: 8266038: Move newAddress() to JVMDebugger In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:19:34 GMT, Yasumasa Suenaga wrote: > SA has `newAddress()` to create `Address` instance, however it is declared in each debugger classes (e.g. `LinuxDebugger`). So we can't access it directly from `VM` class. > > Before SA improvement for ZGC in [JDK-8220624](https://bugs.openjdk.java.net/browse/JDK-8220624), we need to move `newAddress()` to super class (`JVMDebugger`). This pull request has now been integrated. Changeset: b88785d2 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/b88785d2c6945c3063ad264d27609980c359cd77 Stats: 10 lines in 5 files changed: 1 ins; 4 del; 5 mod 8266038: Move newAddress() to JVMDebugger Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/3714 From ysuenaga at openjdk.java.net Wed May 5 00:29:55 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 5 May 2021 00:29:55 GMT Subject: Integrated: 8265505: findsym does not work on remote debug server In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 07:31:43 GMT, Yasumasa Suenaga wrote: > We can see following error when we run `findsym` on CLHSDB which connects to remote debug server. > > > hsdb> verbose true > hsdb> findsym gHotSpotVMTypes > 0x00007f913d4a45b0Error: java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null > java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.cdbg.CDebugger.loadObjectContainingPC(sun.jvm.hotspot.debugger.Address)" because "cdbg" is null > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:618) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2116) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2086) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1957) > 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:282) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:493) > > > The cause of this NPE is that CDebugger is null. It happens when the debugger is running on debugd server. > Command line debugger like CLHSDB can delegate the command to debugd, like `pmap` and `pstack`. `findsym` can also use this scheme. > > This PR has passed serviceability/sa tests on Linux x64. This pull request has now been integrated. Changeset: 8bcebe73 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/8bcebe73d283bd651a0e2d30133e40cca655f335 Stats: 94 lines in 6 files changed: 44 ins; 30 del; 20 mod 8265505: findsym does not work on remote debug server Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/3582 From sspitsyn at openjdk.java.net Wed May 5 01:09:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 01:09:54 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Hi Coleen, This looks good to me in general. I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line: `4005 if (emcp_method_count != 0 && obsolete_method_count != 0 &&` Suppose, the emcp_method_count is equal to 0. Then do we really want to skip marking all the methods of this InstanceKlass as obsolete? Most likely, I'm missing something. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3852 From sspitsyn at openjdk.java.net Wed May 5 02:08:49 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 02:08:49 GMT Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser.typeName()" retruns " double[][]" >> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double" >> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails. >> >> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine. > > Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision: > > - Update ArrayReferenceImpl.java > - Update ArrayTypeImpl.java Hi Fairoz, It looks good to me. It is a good change to get rid of the `findComponentType`. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3658 From fmatte at openjdk.java.net Wed May 5 02:56:05 2021 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Wed, 5 May 2021 02:56:05 GMT Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] [v2] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 07:58:26 GMT, Fairoz Matte wrote: >> findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list >> list = vm.classesByName(parser.typeName()); >> We have "parser.typeName()" retruns " double[][]" >> vm.classesByName("") is expecting the fully qualified name example "java.lang.Double" >> This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails. >> >> There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine. > > Fairoz Matte has updated the pull request incrementally with two additional commits since the last revision: > > - Update ArrayReferenceImpl.java > - Update ArrayTypeImpl.java Hi Serguei, thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3658 From github.com+7947546+tanghaoth90 at openjdk.java.net Wed May 5 06:00:52 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Wed, 5 May 2021 06:00:52 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Tue, 4 May 2021 04:07:52 GMT, Argha C wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142: > >> 140: long usageNanos = containerMetrics.getCpuUsage(); >> 141: if (numPeriods > 0 && usageNanos > 0) { >> 142: long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods); > > We happened to hit an exactly similar problem when running on a container with openjdk15. > > Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. > Is there a good reason `getCpuQuota` is a better alternative? Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp). ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From ysuenaga at openjdk.java.net Wed May 5 06:37:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 5 May 2021 06:37:14 GMT Subject: RFR: 8266531: ZAddress::address() should be removed from SA Message-ID: `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC. After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved. ------------- Commit messages: - 8266531: ZAddress::address() should be removed from SA Changes: https://git.openjdk.java.net/jdk/pull/3868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266531 Stats: 59 lines in 8 files changed: 13 ins; 34 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3868/head:pull/3868 PR: https://git.openjdk.java.net/jdk/pull/3868 From xliu at openjdk.java.net Wed May 5 06:57:59 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 5 May 2021 06:57:59 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Your bugfix looks good to me. I am not a reviewer. I just happen to work on this file recently. You still need reviewer's approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From fmatte at openjdk.java.net Wed May 5 07:15:05 2021 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Wed, 5 May 2021 07:15:05 GMT Subject: Integrated: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 15:03:42 GMT, Fairoz Matte wrote: > findComponentType() logic is wrong. In findComponentType() method, We always get vm.classesByName() retruns empty list > list = vm.classesByName(parser.typeName()); > We have "parser.typeName()" retruns " double[][]" > vm.classesByName("") is expecting the fully qualified name example "java.lang.Double" > This always returns empty list, resulting into ClassNotLoadedException as it assumes the Component class has not yet been loaded, hence the test case fails. > > There was a suggested fix from Egor Ushakov from JetBrains, I am proposing the same to get this fix. I have verified the patch with required testing it works fine. This pull request has now been integrated. Changeset: 82768d9a Author: Fairoz Matte Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/82768d9a31edcfe5b27e75d681d3592c8f4a2ece Stats: 41 lines in 3 files changed: 0 ins; 36 del; 5 mod 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java fails with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3658 From sspitsyn at openjdk.java.net Wed May 5 07:33:53 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 07:33:53 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 20:51:49 GMT, Alex Menkov wrote: >> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) >> The fix: >> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does >> - makes the test java instead of shell >> - added workaround for JDK-8264667 >> - test code is ready to ignore order of attributes > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the fix accordingly feedback Hi Alex, Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3426 From stuefe at openjdk.java.net Wed May 5 08:05:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 08:05:49 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From sspitsyn at openjdk.java.net Wed May 5 08:11:52 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 08:11:52 GMT Subject: RFR: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes [v3] In-Reply-To: References: Message-ID: <8HaujV32aMmFled5Fy9XWD8LLeIDw5YX7Is5j-_1JwY=.6f6ed414-42cf-41ee-8752-834667a2b472@github.com> On Wed, 28 Apr 2021 21:48:15 GMT, Alex Menkov wrote: >> Class loading may cause loading of some other system/internal classes (for example loading of java.util.concurrent classes when an other thread loads some classes concurrently). >> The fix updates ClassPrepare test so it skip events for "unexpected" classes. >> Also it adds a testcase to verify that classes which are explicitly loaded on other thread do not generate ClassPrepare event on the test thread. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > fixed type in otherThread variable name Hi Alex, The fix looks good to me. The logics is more clear now. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3732 From sspitsyn at openjdk.java.net Wed May 5 08:19:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 08:19:54 GMT Subject: RFR: 8265612: revise the help info for jmap histo command [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang wrote: >> This PR revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix indentation issue Hi Lin, It looks good to me. Sorry for being late on this review. Thanks, serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3598 From sspitsyn at openjdk.java.net Wed May 5 08:44:49 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 08:44:49 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga wrote: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. I've looked at the CSR and added a comment with a question. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From sspitsyn at openjdk.java.net Wed May 5 08:55:59 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 08:55:59 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Hi Albert, It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3756 From sspitsyn at openjdk.java.net Wed May 5 09:00:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 09:00:54 GMT Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> Message-ID: <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com> On Fri, 30 Apr 2021 08:06:38 GMT, BuddyLiao wrote: > The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. @buddyliao The test update looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3810 From sspitsyn at openjdk.java.net Wed May 5 09:11:52 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 5 May 2021 09:11:52 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3448 From mli at openjdk.java.net Wed May 5 10:48:55 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 5 May 2021 10:48:55 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com> <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com> <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com> Message-ID: On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> improve jcmd GC.class_histogram to support parallel > > For jmap -histo we have: > > parallel= parallel threads number for heap iteration: > parallel=0 default behavior, use predefined number of threads > parallel=1 disable parallel heap iteration > parallel= use N threads for parallel heap iteration > > It's a bit inconsistent here in that it says , , and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has: > > Options: (options must be specified using the or = syntax) > -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false) > -gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1) > > The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or , or anything like that: > > "Number of parallel threads to use for heap inspection." > "0 (the default) means let the VM determine the number of threads to use. " > "1 means use one thread (disable parallelism). " > "For any other value the VM will try to use the specified number of threads, but might use fewer." > > I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given. @plummercj @sspitsyn Kindly reminder. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From rehn at openjdk.java.net Wed May 5 11:54:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 5 May 2021 11:54:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked Message-ID: Please consider this change which removes the manual transitions to blocked. This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. The object monitor code could be straight forward changed to use this instead of manual transitions. Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. That made it possible to careful use ThreadInVMfromNative in raw monitors. I also remove the early CAS in raw_enter. We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) Passes t1-t7 and manual stressing relevant test groups. ------------- Commit messages: - Removed manual transitions Changes: https://git.openjdk.java.net/jdk/pull/3875/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265753 Stats: 327 lines in 8 files changed: 122 ins; 155 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From coleenp at openjdk.java.net Wed May 5 13:02:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> References: <9izvv99yDgbpyzYA4x_mh5GC36i04ltjSg2XtgRNUAI=.4f1450af-face-4e02-bd40-08df1c3d6723@github.com> Message-ID: On Wed, 5 May 2021 01:07:13 GMT, Serguei Spitsyn wrote: >> Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. >> >> Tested with tier1-6, tiers 7,8 are running and 98% passing. > > Hi Coleen, > > This looks good to me in general. > I'm a little bit puzzled why the check ` emcp_method_count != 0` is needed at the line: > `4005 if (emcp_method_count != 0 && obsolete_method_count != 0 &&` > > Suppose, the emcp_method_count is equal to 0. > Then do we really want to skip marking all the methods of this InstanceKlass as obsolete? > Most likely, I'm missing something. > > Thanks, > Serguei @sspitsyn I think you're right here. If all the newly old methods are obsolete, then we should mark all the methods in the previous versions as obsolete and not skip this. I'll file an issue to investigate this because it's always been this way (and could use a test also). It's too risky to change here. Thanks for the code review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Wed May 5 13:02:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:53 GMT Subject: Integrated: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. This pull request has now been integrated. Changeset: a05e8e24 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/a05e8e24224b047584c3a273fa7b4fef66798dd6 Stats: 78 lines in 4 files changed: 9 ins; 64 del; 5 mod 8266497: Remove unnecessary EMCP liveness indication Reviewed-by: iklam, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From coleenp at openjdk.java.net Wed May 5 13:02:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 5 May 2021 13:02:52 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks for the code review, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From prappo at openjdk.java.net Wed May 5 16:05:59 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 16:05:59 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap Message-ID: This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/3885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266567 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885 From dfuchs at openjdk.java.net Wed May 5 17:27:02 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 17:27:02 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:59:43 GMT, Pavel Rappo wrote: > This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` LGTM. Thanks for fixing the various typos. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3885 From prappo at openjdk.java.net Wed May 5 18:39:14 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 18:39:14 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2] In-Reply-To: References: Message-ID: > This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Fixed more typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/b8113178..6eea552e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885 From prappo at openjdk.java.net Wed May 5 18:47:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 5 May 2021 18:47:53 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:39:14 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Fixed more typos Daniel, would you kindly review the most recent commit, which fixes three more typos? ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From dfuchs at openjdk.java.net Wed May 5 19:24:52 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 19:24:52 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 18:39:14 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Fixed more typos src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java line 308: > 306: public static synchronized JMXConnectorServer initialize() { > 307: > 308: // Load new management properties Debatable. I guess what was meant here is: // Loads a new management Properties instance Otherwise LGTM. ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From amenkov at openjdk.java.net Wed May 5 20:33:06 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 5 May 2021 20:33:06 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 Message-ID: Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. The fix adds synchronization for ClassFileLoadHook. ------------- Commit messages: - Added synchronization for ClassFileLoadHook callback Changes: https://git.openjdk.java.net/jdk/pull/3889/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3889&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262092 Stats: 35 lines in 1 file changed: 22 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3889/head:pull/3889 PR: https://git.openjdk.java.net/jdk/pull/3889 From lmesnik at openjdk.java.net Wed May 5 21:05:52 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 5 May 2021 21:05:52 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 20:26:13 GMT, Alex Menkov wrote: > Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. > The fix adds synchronization for ClassFileLoadHook. Also, generic comment. There are other counters which might require synchronization, like CompiledMethodLoadEventsCount. Doesn't it makes sense to fix them also or file a new bug? test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 71: > 69: static int classCount = 0; > 70: /* lock to access classCount */ > 71: static jrawMonitorID classLoadLock = NULL; I think it would simpler to use an atomic counter rather than monitors for this fix. test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110: > 108: } > 109: // use while instead of if to exit the block on error > 110: while (classCount < max_classes) { Could you please explain why this while is executed only once. It is not obvious. ------------- Changes requested by lmesnik (Committer). PR: https://git.openjdk.java.net/jdk/pull/3889 From github.com+971473+argha-c at openjdk.java.net Wed May 5 21:18:52 2021 From: github.com+971473+argha-c at openjdk.java.net (Argha C) Date: Wed, 5 May 2021 21:18:52 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Wed, 5 May 2021 05:57:55 GMT, Hao Tang wrote: >> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 142: >> >>> 140: long usageNanos = containerMetrics.getCpuUsage(); >>> 141: if (numPeriods > 0 && usageNanos > 0) { >>> 142: long quotaNanos = TimeUnit.MICROSECONDS.toNanos(quota * numPeriods); >> >> We happened to hit an exactly similar problem when running on a container with openjdk15. >> >> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. >> Is there a good reason `getCpuQuota` is a better alternative? > > Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp). Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From amenkov at openjdk.java.net Wed May 5 22:03:00 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 5 May 2021 22:03:00 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:02:44 GMT, Leonid Mesnik wrote: > Also, generic comment. There are other counters which might require synchronization, like CompiledMethodLoadEventsCount. Doesn't it makes sense to fix them also or file a new bug? The problem with classCount is it's used as an index in the arrays. CompiledMethodLoadEventsCount is only incremented (for formally it should be synchronized too). And looks like CompiledMethodLoadEventsCount is actually not used (I mean the values is not checked) ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From amenkov at openjdk.java.net Wed May 5 22:11:50 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 5 May 2021 22:11:50 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 20:59:01 GMT, Leonid Mesnik wrote: >> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. >> The fix adds synchronization for ClassFileLoadHook. > > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 71: > >> 69: static int classCount = 0; >> 70: /* lock to access classCount */ >> 71: static jrawMonitorID classLoadLock = NULL; > > I think it would simpler to use an atomic counter rather than monitors for this fix. Do you mean use from STL? I'm not sure it would be simpler as we need logic like "get the value, if the value is less than max_classes, increment it" ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From amenkov at openjdk.java.net Wed May 5 22:14:52 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 5 May 2021 22:14:52 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:01:11 GMT, Leonid Mesnik wrote: >> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. >> The fix adds synchronization for ClassFileLoadHook. > > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110: > >> 108: } >> 109: // use while instead of if to exit the block on error >> 110: while (classCount < max_classes) { > > Could you please explain why this while is executed only once. It is not obvious. I tried to explain it in the comment :) it should be "if (classCount < max_classes)", but inside the if we have return statements and we need to do cleanup (exit monitor). So I used well-known pattern with 1-pass cycle (note that "return"s are replaced with "break"s) ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From amenkov at openjdk.java.net Wed May 5 22:46:51 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 5 May 2021 22:46:51 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 22:12:20 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 110: >> >>> 108: } >>> 109: // use while instead of if to exit the block on error >>> 110: while (classCount < max_classes) { >> >> Could you please explain why this while is executed only once. It is not obvious. > > I tried to explain it in the comment :) > it should be "if (classCount < max_classes)", > but inside the if we have return statements and we need to do cleanup (exit monitor). > So I used well-known pattern with 1-pass cycle (note that "return"s are replaced with "break"s) Offline discussion shown that I forgot to add break at the end of the cycle. Will fix ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From sspitsyn at openjdk.java.net Thu May 6 00:09:50 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 6 May 2021 00:09:50 GMT Subject: RFR: 8266497: Remove unnecessary EMCP liveness indication In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:31:46 GMT, Coleen Phillimore wrote: > Marking running_emcp for Method* is unnecessary. We can set/clear breakpoints in all old emcp methods because they're not deallocated until none are running. See longer explanation in the CR. > > Tested with tier1-6, tiers 7,8 are running and 98% passing. Thanks, Coleen! I agree, it is better to file a new bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3852 From github.com+3094961+buddyliao at openjdk.java.net Thu May 6 02:30:08 2021 From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao) Date: Thu, 6 May 2021 02:30:08 GMT Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods [v2] In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> Message-ID: > The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. BuddyLiao 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: 8266193: BasicJMapTest does not include testHistoParallel methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3810/files - new: https://git.openjdk.java.net/jdk/pull/3810/files/b922efee..d5edd157 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3810&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3810&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3810/head:pull/3810 PR: https://git.openjdk.java.net/jdk/pull/3810 From github.com+7947546+tanghaoth90 at openjdk.java.net Thu May 6 02:36:54 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Thu, 6 May 2021 02:36:54 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:16:07 GMT, Argha C wrote: > Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation. We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways. 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` & `share`); 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number. Looking forward to your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From lzang at openjdk.java.net Thu May 6 02:58:55 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 6 May 2021 02:58:55 GMT Subject: RFR: 8265612: revise the help info for jmap histo command [v3] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:16:38 GMT, Serguei Spitsyn wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix indentation issue > > Hi Lin, > It looks good to me. Sorry for being late on this review. > Thanks, > serguei Dear @sspitsyn @plummercj Thanks a lot for your help reviewing. May I ask your help to push it? BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3598 From github.com+3094961+buddyliao at openjdk.java.net Thu May 6 03:06:58 2021 From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao) Date: Thu, 6 May 2021 03:06:58 GMT Subject: RFR: 8266193: BasicJMapTest should include testHistoParallel methods [v2] In-Reply-To: <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com> References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com> Message-ID: On Wed, 5 May 2021 08:58:15 GMT, Serguei Spitsyn wrote: > @buddyliao > The test update looks good to me. > Thanks, > Serguei @sspitsyn Thanks, I force update the title to match between PR and JBS. Would you help me to push it? Thanks, Buddy ------------- PR: https://git.openjdk.java.net/jdk/pull/3810 From ksakata at openjdk.java.net Thu May 6 06:24:26 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:24:26 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: Change variable name to better one ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3448/files - new: https://git.openjdk.java.net/jdk/pull/3448/files/e37e8c50..d7b0627f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3448&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3448&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3448/head:pull/3448 PR: https://git.openjdk.java.net/jdk/pull/3448 From ksakata at openjdk.java.net Thu May 6 06:55:59 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:55:59 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 06:24:26 GMT, Koichi Sakata wrote: >> When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. >> >> >> $ java -Xlog::sample.log:: Sample >> $ jcmd 4976 VM.log list >> Log output configuration: >> #0: stdout all=warning uptime,level,tags >> #1: stderr all=off uptime,level,tags >> #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K >> >> $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" >> 4976: >> Output options for existing outputs are ignored. >> >> $ jcmd 4976 VM.log output="#2" output_options="filecount=100" >> 4976: >> Command executed successfully >> >> >> It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. >> >> >> $ jcmd 4976 VM.log list >> #0: stdout all=warning uptime,level,tags >> #1: stderr all=off uptime,level,tags >> #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) >> >> This pull request enable to show the warning message when specifying the output index. >> >> >> $ java -Xlog::sample.log:: Sample >> $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" >> 5054: >> Output options for existing outputs are ignored. >> >> $ jcmd 5054 VM.log output="#2" output_options="filecount=100" >> 5054: >> Output options for existing outputs are ignored. >> >> >> ### gtest result >> >> >> $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* >> Note: Google Test filter = LogConfigurationTest.* >> [==========] Running 15 tests from 1 test case. >> [----------] Global test environment set-up. >> [----------] 15 tests from LogConfigurationTest >> [ RUN ] LogConfigurationTest.describe_vm >> [ OK ] LogConfigurationTest.describe_vm (1 ms) >> [ RUN ] LogConfigurationTest.update_output_vm >> [ OK ] LogConfigurationTest.update_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.add_new_output_vm >> [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.disable_logging_vm >> [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) >> [ RUN ] LogConfigurationTest.disable_output_vm >> [ OK ] LogConfigurationTest.disable_output_vm (0 ms) >> [ RUN ] LogConfigurationTest.reconfigure_decorators_vm >> [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) >> [ RUN ] LogConfigurationTest.invalid_configure_options_vm >> [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) >> [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm >> [0.462s][warning][logging] Ignoring excess -Xlog options: "" >> [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) >> [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm >> [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) >> [ RUN ] LogConfigurationTest.parse_log_arguments_vm >> [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) >> [ RUN ] LogConfigurationTest.configure_stdout_vm >> [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) >> [ RUN ] LogConfigurationTest.subscribe_vm >> [ OK ] LogConfigurationTest.subscribe_vm (2 ms) >> [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm >> [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) >> [ RUN ] LogConfigurationTest.output_name_normalization_vm >> [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) >> [ RUN ] LogConfigurationTest.suggest_similar_selection_vm >> [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) >> [----------] 15 tests from LogConfigurationTest (658 ms total) >> >> [----------] Global test environment tear-down >> [==========] 15 tests from 1 test case ran. (659 ms total) >> [ PASSED ] 15 tests. > > Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: > > Change variable name to better one Thank you for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From ksakata at openjdk.java.net Thu May 6 06:56:00 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 06:56:00 GMT Subject: RFR: 8265047: Inconsistent warning message in jcmd VM.log [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 23:50:16 GMT, David Holmes wrote: >> Koichi Sakata has updated the pull request incrementally with one additional commit since the last revision: >> >> Change variable name to better one > > src/hotspot/share/logging/logConfiguration.cpp line 430: > >> 428: ConfigurationLock cl; >> 429: size_t idx; >> 430: bool is_added = false; > > Nit: `was_added` (or even just `added`) Thank you, David. I changed `is_added` to `added`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From lzang at openjdk.java.net Thu May 6 08:45:45 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 6 May 2021 08:45:45 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request incrementally with one additional commit since the last revision: code refine and typo fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2261/files - new: https://git.openjdk.java.net/jdk/pull/2261/files/6d14790a..bf6d022e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=20-21 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From ksakata at openjdk.java.net Thu May 6 12:11:02 2021 From: ksakata at openjdk.java.net (Koichi Sakata) Date: Thu, 6 May 2021 12:11:02 GMT Subject: Integrated: 8265047: Inconsistent warning message in jcmd VM.log In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 04:23:52 GMT, Koichi Sakata wrote: > When reconfiguring log output options of an existing log setting with jcmd VM.log and the file name, a warning message is shown. However, when reconfiguring them with jcmd VM.log and the output index, the message is not shown. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 4976 VM.log list > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K > > $ jcmd 4976 VM.log output="sample.log" output_options="filecount=100" > 4976: > Output options for existing outputs are ignored. > > $ jcmd 4976 VM.log output="#2" output_options="filecount=100" > 4976: > Command executed successfully > > > It's better to show the same message also in the latter case, I think. Because the output options is not updated in both cases. > > > $ jcmd 4976 VM.log list > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > #2: file=sample.log all=info uptime,level,tags filecount=5,filesize=20480K (reconfigured) > > This pull request enable to show the warning message when specifying the output index. > > > $ java -Xlog::sample.log:: Sample > $ jcmd 5054 VM.log output="sample.log" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > $ jcmd 5054 VM.log output="#2" output_options="filecount=100" > 5054: > Output options for existing outputs are ignored. > > > ### gtest result > > > $ ./build/linux-x86_64-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./build/linux-x86_64-server-fastdebug/jdk --gtest_filter=LogConfigurationTest.* > Note: Google Test filter = LogConfigurationTest.* > [==========] Running 15 tests from 1 test case. > [----------] Global test environment set-up. > [----------] 15 tests from LogConfigurationTest > [ RUN ] LogConfigurationTest.describe_vm > [ OK ] LogConfigurationTest.describe_vm (1 ms) > [ RUN ] LogConfigurationTest.update_output_vm > [ OK ] LogConfigurationTest.update_output_vm (0 ms) > [ RUN ] LogConfigurationTest.add_new_output_vm > [ OK ] LogConfigurationTest.add_new_output_vm (0 ms) > [ RUN ] LogConfigurationTest.disable_logging_vm > [ OK ] LogConfigurationTest.disable_logging_vm (1 ms) > [ RUN ] LogConfigurationTest.disable_output_vm > [ OK ] LogConfigurationTest.disable_output_vm (0 ms) > [ RUN ] LogConfigurationTest.reconfigure_decorators_vm > [ OK ] LogConfigurationTest.reconfigure_decorators_vm (0 ms) > [ RUN ] LogConfigurationTest.invalid_configure_options_vm > [ OK ] LogConfigurationTest.invalid_configure_options_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_empty_command_line_arguments_vm > [0.462s][warning][logging] Ignoring excess -Xlog options: "" > [ OK ] LogConfigurationTest.parse_empty_command_line_arguments_vm (0 ms) > [ RUN ] LogConfigurationTest.parse_command_line_arguments_vm > [ OK ] LogConfigurationTest.parse_command_line_arguments_vm (1 ms) > [ RUN ] LogConfigurationTest.parse_log_arguments_vm > [ OK ] LogConfigurationTest.parse_log_arguments_vm (188 ms) > [ RUN ] LogConfigurationTest.configure_stdout_vm > [ OK ] LogConfigurationTest.configure_stdout_vm (2 ms) > [ RUN ] LogConfigurationTest.subscribe_vm > [ OK ] LogConfigurationTest.subscribe_vm (2 ms) > [ RUN ] LogConfigurationTest.parse_invalid_tagset_vm > [ OK ] LogConfigurationTest.parse_invalid_tagset_vm (0 ms) > [ RUN ] LogConfigurationTest.output_name_normalization_vm > [ OK ] LogConfigurationTest.output_name_normalization_vm (1 ms) > [ RUN ] LogConfigurationTest.suggest_similar_selection_vm > [ OK ] LogConfigurationTest.suggest_similar_selection_vm (1 ms) > [----------] 15 tests from LogConfigurationTest (658 ms total) > > [----------] Global test environment tear-down > [==========] 15 tests from 1 test case ran. (659 ms total) > [ PASSED ] 15 tests. This pull request has now been integrated. Changeset: 51f5adfc Author: Koichi Sakata Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/51f5adfca3854b1556bb73e08e0b3e733ab6161b Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod 8265047: Inconsistent warning message in jcmd VM.log Reviewed-by: dholmes, stuefe, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3448 From sgehwolf at openjdk.java.net Thu May 6 13:54:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 6 May 2021 13:54:54 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com> On Thu, 6 May 2021 02:34:01 GMT, Hao Tang wrote: >> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > >> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > > Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation. > > We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways. > 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` & `share`); > 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number. > > Looking forward to your suggestion. > We happened to hit an exactly similar problem when running on a container with openjdk15. > > Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. > Is there a good reason `getCpuQuota` is a better alternative? @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, *not* shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Thu May 6 13:54:53 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 6 May 2021 13:54:53 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang wrote: > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". @tanghaoth90 There are a couple of ways how CPU restrictions can be enforced. It appears that the current patch fixes the cpuacct controller case (`--cpu-quota`), but doesn't yet address `--cpu-shares` case. I've made a note of that in the bug. ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Thu May 6 13:54:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 6 May 2021 13:54:54 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com> References: <21o75Tv0qUshuro02AKQGZHZCEnHw-zmOznWLKBXUVs=.c6463617-f075-4271-b035-7160b18d1196@github.com> Message-ID: On Thu, 6 May 2021 12:36:09 GMT, Severin Gehwolf wrote: >>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. >> >> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation. >> >> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways. >> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` & `share`); >> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number. >> >> Looking forward to your suggestion. > >> We happened to hit an exactly similar problem when running on a container with openjdk15. >> >> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above. >> Is there a good reason `getCpuQuota` is a better alternative? > > @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, *not* shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-) > Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still). ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From github.com+971473+argha-c at openjdk.java.net Thu May 6 16:34:51 2021 From: github.com+971473+argha-c at openjdk.java.net (Argha C) Date: Thu, 6 May 2021 16:34:51 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:16:07 GMT, Argha C wrote: >> Hi Argha, thanks a lot for your suggestion. I think both "quota" and "share" are worth considering. Let us look into the implementation of `CgroupSubsystem::active_processor_count()` in OpenJDK HotSpot (https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp). > > Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, _not_ shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-) @jerboaa : Correct. My comment was less specific to the branch, and more to highlight that a fix here needs to consider the case for both `quota` and `shares`. I see the bug report has been updated to reflect that. Cheers. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Thu May 6 16:42:53 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 6 May 2021 16:42:53 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load In-Reply-To: References: Message-ID: <_ROoHGcoT4qAjecdgaTT7J-33EwEqfx62sBTZw8TBTw=.f33c4acc-8738-4b68-96d6-39c9191df103@github.com> On Thu, 6 May 2021 16:31:57 GMT, Argha C wrote: >> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > >> @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, _not_ shares are in effect. In docker/podman speach these are `--cpu-quota=...` and `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-) > > @jerboaa : Correct. My comment was less specific to the branch, and more to highlight that a fix here needs to consider the case for both `quota` and `shares`. I see the bug report has been updated to reflect that. Cheers. OK. Thanks for clarifying. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From amenkov at openjdk.java.net Thu May 6 18:37:54 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 6 May 2021 18:37:54 GMT Subject: Integrated: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov wrote: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes This pull request has now been integrated. Changeset: 52f1db6b Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/52f1db6b6f7f5e5823ee84fc31edddf89ed21df4 Stats: 216 lines in 4 files changed: 109 ins; 97 del; 10 mod 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From amenkov at openjdk.java.net Thu May 6 18:40:54 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 6 May 2021 18:40:54 GMT Subject: Integrated: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:30:09 GMT, Alex Menkov wrote: > Class loading may cause loading of some other system/internal classes (for example loading of java.util.concurrent classes when an other thread loads some classes concurrently). > The fix updates ClassPrepare test so it skip events for "unexpected" classes. > Also it adds a testcase to verify that classes which are explicitly loaded on other thread do not generate ClassPrepare event on the test thread. This pull request has now been integrated. Changeset: 0ca86da0 Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/0ca86da0e3563a8328f6ff2a3bc4d4c5b8a82e69 Stats: 81 lines in 2 files changed: 47 ins; 16 del; 18 mod 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3732 From amenkov at openjdk.java.net Thu May 6 18:45:20 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 6 May 2021 18:45:20 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 [v2] In-Reply-To: References: Message-ID: > Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. > The fix adds synchronization for ClassFileLoadHook. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: added missed break; made all counters atomic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3889/files - new: https://git.openjdk.java.net/jdk/pull/3889/files/63e85bc3..6606d89b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3889&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3889&range=00-01 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3889/head:pull/3889 PR: https://git.openjdk.java.net/jdk/pull/3889 From vromero at openjdk.java.net Thu May 6 19:06:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 May 2021 19:06:41 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v7] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 11 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05-06 Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From lmesnik at openjdk.java.net Thu May 6 19:21:52 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 6 May 2021 19:21:52 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:45:20 GMT, Alex Menkov wrote: >> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. >> The fix adds synchronization for ClassFileLoadHook. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > added missed break; made all counters atomic Marked as reviewed by lmesnik (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From kevinw at openjdk.java.net Thu May 6 20:48:00 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 6 May 2021 20:48:00 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container Message-ID: This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. ------------- Commit messages: - 8196743: jstatd doesn't see new Java processes inside Docker container Changes: https://git.openjdk.java.net/jdk/pull/3908/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3908&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196743 Stats: 10 lines in 1 file changed: 5 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3908.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3908/head:pull/3908 PR: https://git.openjdk.java.net/jdk/pull/3908 From larry.cable at oracle.com Thu May 6 21:50:51 2021 From: larry.cable at oracle.com (Laurence Cable) Date: Thu, 6 May 2021 14:50:51 -0700 Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container In-Reply-To: References: Message-ID: and sadly /proc does not support inotify()!!!! On 5/6/21 1:48 PM, Kevin Walls wrote: > This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. > > jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. > > Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. > > ------------- > > Commit messages: > - 8196743: jstatd doesn't see new Java processes inside Docker container > > Changes: https://git.openjdk.java.net/jdk/pull/3908/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3908&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8196743 > Stats: 10 lines in 1 file changed: 5 ins; 3 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/3908.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3908/head:pull/3908 > > PR: https://git.openjdk.java.net/jdk/pull/3908 -------------- next part -------------- A non-text attachment was scrubbed... Name: larry_cable.vcf Type: text/x-vcard Size: 217 bytes Desc: not available URL: From sspitsyn at openjdk.java.net Thu May 6 23:57:22 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 6 May 2021 23:57:22 GMT Subject: RFR: 8266193: BasicJMapTest does not include testHistoParallel methods [v2] In-Reply-To: References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> <5kkIscThLm820VsCd91EKWYPoYXXT20ZPbYNo5s2OLg=.ade64cda-f8a2-490e-b3aa-1ffdb7a3f95b@github.com> Message-ID: On Thu, 6 May 2021 03:03:40 GMT, BuddyLiao wrote: >> @buddyliao >> The test update looks good to me. >> Thanks, >> Serguei > >> @buddyliao >> The test update looks good to me. >> Thanks, >> Serguei > > @sspitsyn Thanks, I have forced update the title to match between PR and JBS. > Would you help me to push it? > > Thanks, > Buddy @buddyliao Two reviews are required for serviceability fixes. I'll sponsor it once you get another review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3810 From ysuenaga at openjdk.java.net Thu May 6 23:57:51 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 6 May 2021 23:57:51 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls wrote: > This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. > > jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. > > Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 79: > 77: public LocalVmManager(String user) { > 78: this.userName = user; > 79: setTempDirs(); Is this call necessary? It looks like we don't need to hold `tmpdirs` anymore. Can we remove `tmpdirs` from class member and can call `PerfDataFile.getTempDirectories()` directly at L138? ------------- PR: https://git.openjdk.java.net/jdk/pull/3908 From sspitsyn at openjdk.java.net Fri May 7 00:25:11 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 7 May 2021 00:25:11 GMT Subject: RFR: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 18:45:20 GMT, Alex Menkov wrote: >> Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. >> The fix adds synchronization for ClassFileLoadHook. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > added missed break; made all counters atomic This looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3889 From sspitsyn at openjdk.java.net Fri May 7 00:33:59 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 7 May 2021 00:33:59 GMT Subject: RFR: 8265612: revise the help info for jmap histo command [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang wrote: >> This PR revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix indentation issue Hi Lin, I've added a comment with the /sponsor, so you can push it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3598 From lzang at openjdk.java.net Fri May 7 00:33:59 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 7 May 2021 00:33:59 GMT Subject: RFR: 8265612: revise the help info for jmap histo command [v3] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 00:26:55 GMT, Serguei Spitsyn wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix indentation issue > > Hi Lin, > I've added a comment with the /sponsor, so you can push it now. Hi @sspitsyn?Thanks a lot? ------------- PR: https://git.openjdk.java.net/jdk/pull/3598 From sspitsyn at openjdk.java.net Fri May 7 00:42:53 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 7 May 2021 00:42:53 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls wrote: > This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. > > jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. > > Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. Hi Kevin, This looks okay to me modulo the question from Yasumasa. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3908 From lzang at openjdk.java.net Fri May 7 02:00:11 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 7 May 2021 02:00:11 GMT Subject: RFR: 8265612: revise the help info for jmap histo command [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 05:53:35 GMT, Lin Zang wrote: >> This PR revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186. > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > fix indentation issue Hi Serguei, Sorry that I forgot to add /integrate tag before asking your help sponsor, it seems I need your help to mark this PR again with /sponsor tag, Would you like to help again. Thanks a lot! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3598 From amenkov at openjdk.java.net Fri May 7 02:03:50 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 7 May 2021 02:03:50 GMT Subject: RFR: 8266193: BasicJMapTest does not include testHistoParallel methods [v2] In-Reply-To: References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> Message-ID: On Thu, 6 May 2021 02:30:08 GMT, BuddyLiao wrote: >> The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. > > BuddyLiao 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: > > 8266193: BasicJMapTest does not include testHistoParallel methods Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3810 From github.com+3094961+buddyliao at openjdk.java.net Fri May 7 03:00:56 2021 From: github.com+3094961+buddyliao at openjdk.java.net (BuddyLiao) Date: Fri, 7 May 2021 03:00:56 GMT Subject: Integrated: 8266193: BasicJMapTest does not include testHistoParallel methods In-Reply-To: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> References: <06-HQLQgDE1NeUQ-nPoeF7gKuaeuL1J_YJZwWsPLoAg=.2933c8a7-228d-4502-9057-3554fb07a679@github.com> Message-ID: On Fri, 30 Apr 2021 08:06:38 GMT, BuddyLiao wrote: > The testHistoParallel* method are not included in the BasicJMapTest's main() method. They should be included. This pull request has now been integrated. Changeset: 66191ff4 Author: buddyliao Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/66191ff4b04f03172e8b7b28184a7f39ce3804bd Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8266193: BasicJMapTest does not include testHistoParallel methods Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/3810 From lzang at openjdk.java.net Fri May 7 04:44:14 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 7 May 2021 04:44:14 GMT Subject: Integrated: 8265612: revise the help info for jmap histo command In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 02:18:12 GMT, Lin Zang wrote: > This PR revise the help message of the `parallel=[N]` option of command `jmap -histo`. It mainly comes from the discussion at https://github.com/openjdk/jdk/pull/2379#issuecomment-782609582 and https://github.com/openjdk/jdk/pull/2261#issuecomment-823623186. This pull request has now been integrated. Changeset: 3a474d95 Author: Lin Zang Committer: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/3a474d953a608a0e4b40a4d0b53ec3e98d73f406 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8265612: revise the help info for jmap histo command Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3598 From kevinw at openjdk.java.net Fri May 7 09:15:14 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 7 May 2021 09:15:14 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container [v2] In-Reply-To: References: Message-ID: > This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. > > jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. > > Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove tmpdirs member, call getTempDirectories() directly as needed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3908/files - new: https://git.openjdk.java.net/jdk/pull/3908/files/658a9e27..3654447b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3908&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3908&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3908.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3908/head:pull/3908 PR: https://git.openjdk.java.net/jdk/pull/3908 From kevinw at openjdk.java.net Fri May 7 09:15:15 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 7 May 2021 09:15:15 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 23:54:49 GMT, Yasumasa Suenaga wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove tmpdirs member, call getTempDirectories() directly as needed. > > src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java line 79: > >> 77: public LocalVmManager(String user) { >> 78: this.userName = user; >> 79: setTempDirs(); > > Is this call necessary? It looks like we don't need to hold `tmpdirs` anymore. Can we remove `tmpdirs` from class member and can call `PerfDataFile.getTempDirectories()` directly at L138? Hi - right, it's not necessary, I almost took it out, but had a minor concern about leaving tmpdirs unset. But removing tmpdirs as a member is fine also. That is testing well, will push an update shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3908 From ysuenaga at openjdk.java.net Fri May 7 09:18:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 7 May 2021 09:18:53 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container [v2] In-Reply-To: References: Message-ID: On Fri, 7 May 2021 09:15:14 GMT, Kevin Walls wrote: >> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. >> >> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. >> >> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove tmpdirs member, call getTempDirectories() directly as needed. Looks good! Thank you for fixing! ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3908 From lzang at openjdk.java.net Fri May 7 15:41:00 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 7 May 2021 15:41:00 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Tue, 20 Apr 2021 21:55:40 GMT, Chris Plummer wrote: >> Lin Zang 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 ten additional commits since the last revision: >> >> - Merge branch 'master' >> - Merge branch 'master' into sf >> - rename writeThrough to unbufferedMode and code refine >> - fix typo in comments >> - Merge branch 'master' into sf >> - Revert "reduce memory consumption" >> >> This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e. >> - reduce memory consumption >> - code refine >> - 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out > > I think it's fine to fix this issue first with something simpler, and worry about the rewrite later. Hi Chris (@plummercj ) After several tries, I think maybe the current patch is the better way to fix this issue. For detail, there are three issues that cause the problem. - The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR. - The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. - Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow) Here are the possible solutions I have tried to avoid using `unbufferedMode`: - For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array: The original limitation is MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size. But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean. - I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic. And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments. Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. What do you think? Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From kevinw at openjdk.java.net Fri May 7 15:46:56 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 7 May 2021 15:46:56 GMT Subject: RFR: 8196743: jstatd doesn't see new Java processes inside Docker container [v2] In-Reply-To: References: Message-ID: <96hUWjwEDumCR3Q6TdrAWgmkOaUyZClG7bFkATZ2ABw=.dd86b32d-20cb-4497-ad3b-dc4c6400340b@github.com> On Fri, 7 May 2021 09:15:14 GMT, Kevin Walls wrote: >> This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. >> >> jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. >> >> Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove tmpdirs member, call getTempDirectories() directly as needed. (For the record, the tier1_serviceability tests run OK for me.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3908 From kevinw at openjdk.java.net Fri May 7 15:46:56 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 7 May 2021 15:46:56 GMT Subject: Integrated: 8196743: jstatd doesn't see new Java processes inside Docker container In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:41:40 GMT, Kevin Walls wrote: > This is a merge request to fix the issue where a running jstatd does not see JVMs in docker containers started since the jstatd itself started. > > jstatd was using the set of temp directories gathered on startup to scan for VMs, by reading their perfdata file. That includes existing running VMs in docker instances using tmp dirs such as /proc/PID/root/tmp/. But it needs to re-evaluate that set of temp dirs continually to see new VMs in docker containers. Rescanning also means it "forgets" about tmp dirs which have disappeared, for containers that have shutdown, and it will now not be scanning those directories forever. > > Have been testing this manually, watching jps connecting to jstatd and show newly created JVMs in docker containers come and go. Running existing tests OK so far. This pull request has now been integrated. Changeset: 0790e601 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/0790e6016e153b4fa4df5d80737f90aa555c7ba9 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod 8196743: jstatd doesn't see new Java processes inside Docker container Reviewed-by: sspitsyn, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/3908 From coleenp at openjdk.java.net Sun May 9 22:54:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sun, 9 May 2021 22:54:08 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David I started out thinking that this was too big and should be broken up but then the change is pretty simple to review and mostly mechanical. So ignore my comments to break it up. I think it's fine. Hitting "approve" even though it's a draft. src/hotspot/share/cds/archiveBuilder.cpp line 903: > 901: > 902: static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) { > 903: ResourceMark rm(THREAD); This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread. src/hotspot/share/cds/dynamicArchive.cpp line 172: > 170: _header = mapinfo->dynamic_header(); > 171: > 172: Thread* THREAD = Thread::current(); Unused? Looks like you could also remove these in a trivial pre-commit. src/hotspot/share/classfile/classLoader.cpp line 1077: > 1075: > 1076: // Search either the patch-module or exploded build entries for class. > 1077: ClassFileStream* ClassLoader::search_module_entries(JavaThread* current, I wonder if these CDS and classLoader.hpp/cpp changes can be done first? Just change the caller to pass ->as_Java_thread() until TRAPS is changed. src/hotspot/share/runtime/sharedRuntime.cpp line 1197: > 1195: > 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) { > 1197: JavaThread* current = THREAD; I think these look strange, especially the ones JavaThread* thread = THREAD; but they can be fixed later to just use THREAD when THREAD is available. And it's not really important. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3877 From dholmes at openjdk.java.net Sun May 9 22:54:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 9 May 2021 22:54:07 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments Message-ID: Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done that pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param - Manifestations of Thread::current() become JavaThread::current() - THREAD->as_Java_thread() becomes just THREAD - THREAD->is_Java_thread() is reworked so that THREAD is "current" There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. Testing: - tiers 1-8 on Linux-x64 - all builds in tiers 1-4 - tiers 1-3 on all platforms Thanks, David ------------- Commit messages: - Merge - 8252685: APIs that require JavaThread should take JavaThread arguments Changes: https://git.openjdk.java.net/jdk/pull/3877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252685 Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod Patch: https://git.openjdk.java.net/jdk/pull/3877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877 PR: https://git.openjdk.java.net/jdk/pull/3877 From dholmes at openjdk.java.net Sun May 9 22:54:08 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 9 May 2021 22:54:08 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David Thanks for the pre-review comments Coleen! I started responding to your various comments then realized they were the ones about breaking things up that you said I could now ignore :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From dholmes at openjdk.java.net Sun May 9 22:54:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 9 May 2021 22:54:10 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Sat, 8 May 2021 13:06:01 GMT, Coleen Phillimore wrote: >> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: >> >> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) >> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param >> - Manifestations of Thread::current() become JavaThread::current() >> - THREAD->as_Java_thread() becomes just THREAD >> - THREAD->is_Java_thread() is reworked so that THREAD is "current" >> >> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. >> >> Testing: >> - tiers 1-8 on Linux-x64 >> - all builds in tiers 1-4 >> - tiers 1-3 on all platforms >> >> Thanks, >> David > > src/hotspot/share/cds/archiveBuilder.cpp line 903: > >> 901: >> 902: static void write_klass(Klass* k, address runtime_dest, const char* type_name, int bytes, Thread* THREAD) { >> 903: ResourceMark rm(THREAD); > > This change seems like it could be an independent check in because all you did was change the name of the parameter here, ie doesn't depend on on THREAD being a JavaThread. Under these changes THREAD is always a JavaThread so I either need to change the type here (which would be wrong) or else change the name, because it doesn't actually relate to TRAPS/exceptions. As this change touches a lot of files keeping it merged it time consuming so I'd prefer not to have to split out anything further at this stage. Thanks. > src/hotspot/share/cds/dynamicArchive.cpp line 172: > >> 170: _header = mapinfo->dynamic_header(); >> 171: >> 172: Thread* THREAD = Thread::current(); > > Unused? Looks like you could also remove these in a trivial pre-commit. Yes unused. Again trying to avoid further delays. Also I think this code just went through an undo and will soon be redone, in which case if it gets integrated first I'll try to get this cleaned up. Thanks. > src/hotspot/share/runtime/sharedRuntime.cpp line 1197: > >> 1195: >> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) { >> 1197: JavaThread* current = THREAD; > > I think these look strange, especially the ones > JavaThread* thread = THREAD; > but they can be fixed later to just use THREAD when THREAD is available. And it's not really important. They are the inverse of the JavaThread* THREAD = current; // For exception macro use. due to the general trend to not use THREAD for non-exception related code except in some trivial cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From github.com+2217224+kariya-mitsuru at openjdk.java.net Mon May 10 06:27:12 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Mon, 10 May 2021 06:27:12 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 04:41:20 GMT, Chris Plummer wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > @kariya-mitsuru Please enable github actions on your jdk personal fork to enable the pre-submit testing. Start with the following link: > > https://github.com/kariya-mitsuru/jdk/actions > > Click on "Settings" tab and then click on "Actions" from the list of settings (not the "Actions" tab). Then enable "Allow all Actions". @plummercj Would you please check the changes again? Also, should I issue the /contributor command? ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From coleenp at openjdk.java.net Mon May 10 12:35:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 10 May 2021 12:35:52 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Sun, 9 May 2021 22:42:26 GMT, David Holmes wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 1197: >> >>> 1195: >>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) { >>> 1197: JavaThread* current = THREAD; >> >> I think these look strange, especially the ones >> JavaThread* thread = THREAD; >> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important. > > They are the inverse of the > > JavaThread* THREAD = current; // For exception macro use. > > due to the general trend to not use THREAD for non-exception related code except in some trivial cases. I know what they are. I think if we already have a THREAD then there's no point having another thread or current variable and it's noisy and confusing, ie. we *know* that THREAD is the current thread by definition and 'current' seems to suggest by name but no guarantee of that, and 'thread' is just generic and means nothing. I don't think there should be another variable introduced for Handles and ResourceMarks. Using another variable for last_frame and such might make some sense. Anyway, my definition of "trivial" cases might be more broad than yours. It's not for this change, though, this change is fine, even though I think these extra declarations should be removed at some later date if the code changes for some other reason. ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From amenkov at openjdk.java.net Mon May 10 22:51:32 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Mon, 10 May 2021 22:51:32 GMT Subject: Integrated: 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 20:26:13 GMT, Alex Menkov wrote: > Class loading can happen on different threads, but HotSwap agent is not ready to this - classCount variable is used without any synchronization. > The fix adds synchronization for ClassFileLoadHook. This pull request has now been integrated. Changeset: 9713152e Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/9713152eae660f83b8a681c3168b7eb2285c05bc Stats: 43 lines in 1 file changed: 24 ins; 7 del; 12 mod 8262092: vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t001/TestDescription.java SIGSEGV in memmove_ssse3 Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3889 From sspitsyn at openjdk.java.net Mon May 10 23:00:26 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 10 May 2021 23:00:26 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108: > 106: > 107: // caller needs ResourceMark > 108: const char* get_java_thread_name(const JavaThread* t) { Nit: Better to rename it: t => jt ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From sspitsyn at openjdk.java.net Mon May 10 23:14:07 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 10 May 2021 23:14:07 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David David, This looks pretty good. At least, I do not see real problems. It is really nice to make it more consistent. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3877 From cjplummer at openjdk.java.net Mon May 10 23:18:03 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:18:03 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation In-Reply-To: References: Message-ID: On Mon, 10 May 2021 06:24:23 GMT, Mitsuru kariya wrote: > Also, should I issue the /contributor command? I don't think you need to. I tried using it to add you as a contributor because I thought it might be necessary since you don't have an openjdk username yet, but I was told that it is not necessary since you are the author of the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From cjplummer at openjdk.java.net Mon May 10 23:22:55 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:22:55 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Fri, 7 May 2021 15:37:34 GMT, Lin Zang wrote: > Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review? ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From cjplummer at openjdk.java.net Mon May 10 23:33:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:33:08 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 08:45:45 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request incrementally with one additional commit since the last revision: > > code refine and typo fix I think you still need to undo the JMap.java changes since they are now being handled by #3598 ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From cjplummer at openjdk.java.net Mon May 10 23:41:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:41:59 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v3] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 16:07:26 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Add some more SA's classes Some of the more recently changed files need updates to the Oracle copyrights. WindbgAARCH64Thread.java is a bit different in that it currently only has a 2020 date. It should be changed to the following: ` * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.` Note I'm only requesting updates to the Oracle copyrights. ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From cjplummer at openjdk.java.net Mon May 10 23:46:24 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 10 May 2021 23:46:24 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. Marked as reviewed by cjplummer (Reviewer). Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From cjplummer at openjdk.java.net Tue May 11 00:03:54 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 11 May 2021 00:03:54 GMT Subject: RFR: 8266531: ZAddress::address() should be removed from SA In-Reply-To: References: Message-ID: On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga wrote: > `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC. > After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved. The changes look good. I think it would be best if the 2nd review came from the GC team. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3868 From ysuenaga at openjdk.java.net Tue May 11 00:07:56 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 11 May 2021 00:07:56 GMT Subject: RFR: 8266531: ZAddress::address() should be removed from SA In-Reply-To: References: Message-ID: <5-R87iV_MuMbTLp1IlDDw9r0sR8bjgXEMpHAqYikXwg=.45d0e616-60d2-4251-a5ea-807ec3f0dd34@github.com> On Tue, 11 May 2021 00:00:35 GMT, Chris Plummer wrote: > The changes look good. Thanks! > I think it would be best if the 2nd review came from the GC team. I think so too, I'm waiting for the review from GC folks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3868 From ysuenaga at openjdk.java.net Tue May 11 00:15:21 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 11 May 2021 00:15:21 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: Message-ID: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Update jhsdb man page - Merge remote-tracking branch 'upstream/master' into JDK-8263635 - Update help message - 8263635: Add --prefix option to jhsdb debugd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3669/files - new: https://git.openjdk.java.net/jdk/pull/3669/files/90a9d014..af154a77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=00-01 Stats: 512695 lines in 4306 files changed: 25267 ins; 478859 del; 8569 mod Patch: https://git.openjdk.java.net/jdk/pull/3669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669 PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Tue May 11 00:15:22 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 11 May 2021 00:15:22 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:41:48 GMT, Serguei Spitsyn wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > I've looked at the CSR and added a comment with a question. @sspitsyn Thanks for your comment! I updated the CSR, and pushed new commits to follow it. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From cjplummer at openjdk.java.net Tue May 11 00:55:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 11 May 2021 00:55:09 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: Message-ID: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> On Tue, 11 May 2021 00:15:21 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA remote object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. And also we should add the way to specify the prefix when we connect to debug server. I will add it like `--connect id at server:1234/prefix`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Update jhsdb man page > - Merge remote-tracking branch 'upstream/master' into JDK-8263635 > - Update help message > - 8263635: Add --prefix option to jhsdb debugd src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93: > 91: > 92: public static Remote lookup(String debugServerID) throws DebuggerException { > 93: // debugServerID follows the pattern [unique_id@]host[:port][/prefix] It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Tue May 11 01:36:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 11 May 2021 01:36:58 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> Message-ID: On Tue, 11 May 2021 00:52:12 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Update jhsdb man page >> - Merge remote-tracking branch 'upstream/master' into JDK-8263635 >> - Update help message >> - 8263635: Add --prefix option to jhsdb debugd > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93: > >> 91: >> 92: public static Remote lookup(String debugServerID) throws DebuggerException { >> 93: // debugServerID follows the pattern [unique_id@]host[:port][/prefix] > > It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this? "prefix" is similar to "unique_id" as you said, but it is useful to group debugees. For example, the host runs 2 container pods as following: * Pod A * Container 1 * Container 2 * Container 3 * Pod B * Container 1 * Container 2 * Container 3 If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1". However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From david.holmes at oracle.com Tue May 11 01:55:58 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 11:55:58 +1000 Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On 11/05/2021 9:14 am, Serguei Spitsyn wrote: > On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > > David, > This looks pretty good. At least, I do not see real problems. > It is really nice to make it more consistent. > Thanks, > Serguei Thanks for the review Serguei! David > ------------- > > Marked as reviewed by sspitsyn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3877 > From dholmes at openjdk.java.net Tue May 11 01:56:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 11 May 2021 01:56:21 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v2] In-Reply-To: References: Message-ID: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Review feedback from Serguei ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3877/files - new: https://git.openjdk.java.net/jdk/pull/3877/files/3b74085a..b08c19cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877 PR: https://git.openjdk.java.net/jdk/pull/3877 From david.holmes at oracle.com Tue May 11 01:58:27 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 May 2021 11:58:27 +1000 Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: <49ecd1f6-fdde-99eb-ea7f-82240615b68f@oracle.com> On 11/05/2021 9:00 am, Serguei Spitsyn wrote: > On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > > src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108: > >> 106: >> 107: // caller needs ResourceMark >> 108: const char* get_java_thread_name(const JavaThread* t) { > > Nit: Better to rename it: t => jt Changed. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3877 > From lzang at openjdk.java.net Tue May 11 03:19:05 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 03:19:05 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - remove parallel option and dumpheapext command - Revert "hide the dumpheapext error message" This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=22 Stats: 840 lines in 5 files changed: 653 ins; 61 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Tue May 11 03:26:07 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 03:26:07 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> code refine and typo fix > > I think you still need to undo the JMap.java changes since they are now being handled by #3598 Hi @plummercj , Thanks for your patience reviewing it over and over again! I have undo the JMap.java and sync with latest master. BRs, LIn ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From github.com+2217224+kariya-mitsuru at openjdk.java.net Tue May 11 06:35:43 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Tue, 11 May 2021 06:35:43 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v4] In-Reply-To: References: Message-ID: > The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. > This PR changes to use `Long.hashCode` instead. Mitsuru kariya 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/3522/files - new: https://git.openjdk.java.net/jdk/pull/3522/files/ac5c2660..71b663cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3522&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3522&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3522/head:pull/3522 PR: https://git.openjdk.java.net/jdk/pull/3522 From stefank at openjdk.java.net Tue May 11 06:37:52 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 11 May 2021 06:37:52 GMT Subject: RFR: 8266531: ZAddress::address() should be removed from SA In-Reply-To: References: Message-ID: On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga wrote: > `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC. > After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved. The HotSpot changes look good. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3868 From github.com+2217224+kariya-mitsuru at openjdk.java.net Tue May 11 07:09:54 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru kariya) Date: Tue, 11 May 2021 07:09:54 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation In-Reply-To: References: Message-ID: On Mon, 10 May 2021 23:15:29 GMT, Chris Plummer wrote: > I don't think you need to. Sure. > Some of the more recently changed files need updates to the Oracle copyrights. I'm sorry for the stupid mistake. I just updated the copyright. > Note I'm only requesting updates to the Oracle copyrights. I made no change to ShenandoahHeapRegion.java since it has no Oracle copyright line. If the line need to be added, could you please let me know? ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From lzang at openjdk.java.net Tue May 11 08:35:37 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 08:35:37 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: <5vKXRileYX5AYzaEn2RoG0ZATMI14tov2QkdufS12Do=.b1fc3088-d00b-4ac5-85ad-00c812448d79@github.com> On Mon, 10 May 2021 23:19:37 GMT, Chris Plummer wrote: >> Hi Chris (@plummercj ) >> >> After several tries, I think maybe the current patch is the better way to fix this issue. >> For detail, there are three issues that cause the problem. >> - The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR. >> - The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. >> - Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow) >> >> Here are the possible solutions I have tried to avoid using `unbufferedMode`: >> >> - For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array: The original limitation is MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size. But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. >> The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean. >> >> - I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic. >> >> And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. >> >> The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments. >> >> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. >> >> What do you think? >> >> Thanks, >> Lin > >> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. > > I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review? Hi @plummercj, I think it is now ready for final review. Thanks a lot! -Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From lzang at openjdk.java.net Tue May 11 08:35:36 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Tue, 11 May 2021 08:35:36 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v9] In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: <36Z_jPBtZtFp33jBw41uFpVJFFDb-b8sLts_uvWtbLg=.8d9ad6ee-38a9-4544-a3c2-ae1064a0264d@github.com> > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out Lin Zang 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 11 additional commits since the last revision: - fix typo in comments - Merge branch 'master' into s-fix - Merge branch 'master' - Merge branch 'master' into sf - rename writeThrough to unbufferedMode and code refine - fix typo in comments - Merge branch 'master' into sf - Revert "reduce memory consumption" This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e. - reduce memory consumption - code refine - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0504cf2b...67f6d985 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2803/files - new: https://git.openjdk.java.net/jdk/pull/2803/files/70dbbfea..67f6d985 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=07-08 Stats: 597367 lines in 5749 files changed: 64391 ins; 518662 del; 14314 mod Patch: https://git.openjdk.java.net/jdk/pull/2803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803 PR: https://git.openjdk.java.net/jdk/pull/2803 From rehn at openjdk.java.net Tue May 11 12:13:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 11 May 2021 12:13:33 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn 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 two additional commits since the last revision: - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/e16e2c30..07ddf393 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=00-01 Stats: 15745 lines in 431 files changed: 9555 ins; 3584 del; 2606 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From hseigel at openjdk.java.net Tue May 11 12:58:07 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 11 May 2021 12:58:07 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass Message-ID: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. Thanks, Harold ------------- Commit messages: - 8243287: Removal of Unsafe::defineAnonymousClass Changes: https://git.openjdk.java.net/jdk/pull/3974/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243287 Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod Patch: https://git.openjdk.java.net/jdk/pull/3974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 PR: https://git.openjdk.java.net/jdk/pull/3974 From brian.goetz at oracle.com Tue May 11 13:20:27 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 May 2021 13:20:27 +0000 Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?. Did you do a search for these idioms too, which are now dead tests? Sent from my iPad > On May 11, 2021, at 8:59 AM, Harold Seigel wrote: > > ?Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold > > ------------- > > Commit messages: > - 8243287: Removal of Unsafe::defineAnonymousClass > > Changes: https://git.openjdk.java.net/jdk/pull/3974/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8243287 > Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod > Patch: https://git.openjdk.java.net/jdk/pull/3974.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 > > PR: https://git.openjdk.java.net/jdk/pull/3974 From alanb at openjdk.java.net Tue May 11 13:40:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 11 May 2021 13:40:54 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel wrote: > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold test/jdk/java/lang/Class/GetModuleTest.java line 42: > 40: import static org.testng.Assert.*; > 41: > 42: public class GetModuleTest { testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From alanb at openjdk.java.net Tue May 11 13:45:01 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 11 May 2021 13:45:01 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Tue, 11 May 2021 13:37:32 GMT, Alan Bateman wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > test/jdk/java/lang/Class/GetModuleTest.java line 42: > >> 40: import static org.testng.Assert.*; >> 41: >> 42: public class GetModuleTest { > > testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal. Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Tue May 11 14:10:42 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 11 May 2021 14:10:42 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v2] In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: test fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3974/files - new: https://git.openjdk.java.net/jdk/pull/3974/files/233a4725..35c6634c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Tue May 11 14:13:49 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 11 May 2021 14:13:49 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix GetModuleTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3974/files - new: https://git.openjdk.java.net/jdk/pull/3974/files/35c6634c..874a1603 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Tue May 11 14:13:51 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 11 May 2021 14:13:51 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Tue, 11 May 2021 13:41:53 GMT, Alan Bateman wrote: >> test/jdk/java/lang/Class/GetModuleTest.java line 42: >> >>> 40: import static org.testng.Assert.*; >>> 41: >>> 42: public class GetModuleTest { >> >> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you can remove the imports as part of the removal. > > Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk. Hi Alan, Thanks for find this. I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From harold.seigel at oracle.com Tue May 11 14:15:10 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 11 May 2021 10:15:10 -0400 Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> Message-ID: <8013d5ad-b06f-29c1-9287-e3408ec86413@oracle.com> Hi Brian, Thanks for looking at this. The JDK no longer creates unsafe anon classes.? So, those tests could only find an unsafe anonymous class if they explicitly created one.? In which case, the tests would need to call Unsafe.defineAnonymousClass().? And, hopefully, those tests have been handled in this webrev. If there are dead tests then they probably died when the JDK stopped creating unsafe anon classes.? Note that none of them showed up as failures during regression testing. Harold On 5/11/2021 9:20 AM, Brian Goetz wrote: > There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?. Did you do a search for these idioms too, which are now dead tests? > > Sent from my iPad > >> On May 11, 2021, at 8:59 AM, Harold Seigel wrote: >> >> ?Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold >> >> ------------- >> >> Commit messages: >> - 8243287: Removal of Unsafe::defineAnonymousClass >> >> Changes: https://git.openjdk.java.net/jdk/pull/3974/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8243287 >> Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod >> Patch: https://git.openjdk.java.net/jdk/pull/3974.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 >> >> PR: https://git.openjdk.java.net/jdk/pull/3974 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 11 14:57:32 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 11 May 2021 14:57:32 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v2] In-Reply-To: References: Message-ID: <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com> > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". Hao Tang has updated the pull request incrementally with one additional commit since the last revision: cpu.shares for OperatingSystemImpl.getCpuLoad() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3656/files - new: https://git.openjdk.java.net/jdk/pull/3656/files/b052b624..81867f21 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=00-01 Stats: 18 lines in 1 file changed: 15 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 11 15:52:01 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 11 May 2021 15:52:01 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 02:34:01 GMT, Hao Tang wrote: >> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > >> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. > > Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation. > > We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways. > 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` & `share`); > 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number. > > Looking forward to your suggestion. > @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still). @jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example. 1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of long usageNanos = containerMetrics.getCpuUsage(); is an accumulated CPU usage rather than a real-time CPU usage. According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue. 2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`. Any suggestion is appreciated. @jerboaa @argha-c ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From iklam at openjdk.java.net Tue May 11 17:12:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 11 May 2021 17:12:23 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> Message-ID: On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix GetModuleTest.java The CDS VM and test changes look OK to me. src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65: > 63: // so when handling the java mirror for the class we need to make sure its class > 64: // loader data is claimed, this is done by calling do_cld explicitly. > 65: // For non-string hidden classes the call to do_cld is made when the class Typo: non-strong ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3974 From dcubed at openjdk.java.net Tue May 11 19:12:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 19:12:01 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 12:13:33 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn 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 two additional commits since the last revision: > > - Merge branch 'master' into 8265753 > - Removed manual transitions Thumbs up on the over all logic. I only have minor nits and suggestions. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 242: > 240: if (self->is_Java_thread()) { > 241: JavaThread* jt = self->as_Java_thread(); > 242: guarantee(jt->thread_state() == _thread_in_native, "invariant"); Thanks for making this a guarantee()! There is an existing assert() about this in: ThreadInVMfromNative -> trans() -> transition_from_native() so it doesn't have to be there for forever. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320: > 318: // JavaThreads will enter here with state _thread_in_native. > 319: void JvmtiRawMonitor::raw_enter(Thread* self) { > 320: // TODO Atomic::load on _owner field Why is this still a TODO? src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42: > 40: // Important note: > 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM > 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint nit typo: s/e.g./e.g.,/ nit typo: s/tranisition/transition/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43: > 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM > 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint > 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread, nit typo: s/VM thread/the VM thread/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > 46: // The rules are: > 47: // - We must never safepoint poll if raw monitor is owned. > 48: // - We may safepoint poll before it is owned and after it have been released. nit typo: s/have been/has been/ src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > 50: // native for all operations. However we need to honor suspend request, not > 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened > 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe nit typo: s/suspend request/a suspend request/ nit typo: s/Honoring suspened/Honoring a suspend request/ nit typo: s/interrupt flag/the interrupt flag/ (You'll probably want to reformat the changed lines a bit.) src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206: > 204: ~ThreadInVMfromNative() { > 205: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); > 206: _thread->set_thread_state(_thread_in_native); You're losing the assertion that we're transitioning from `_thread_in_vm` to `_thread_in_native` here. Although, the constructor did verify that we were in `_thread_in_native` when we transitioned to `_thread_in_vm` so at least the first half is still verified. Can you an assertion that we're in `_thread_in_vm` here? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: > 228: }; > 229: > 230: template When you mentioned doing this with templates, I was having nightmares, but this one is not bad at all... src/hotspot/share/runtime/objectMonitor.cpp line 313: > 311: if (current->is_suspended()) { > 312: _om->_recursions = 0; > 313: _om->_succ = NULL; Please add a comment after this line: // Don't need a full fence after clearing successor here because of the call to exit(). src/hotspot/share/runtime/objectMonitor.cpp line 325: > 323: OrderAccess::fence(); // always do a full fence when successor is cleared > 324: } > 325: _om_exit = true; Hmmm... `_om_exit` flag is misnamed here since you're "only" clearing the successor. Update: Now I see that the ClearSuccOnSuspend class is subclassed from the ExitOnSuspend, but I still find that flag a bit confusing. src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _om_exit; Instead of `_om_exit` maybe this should be more generic? Perhaps `_om_op_done` or something like that? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From cjplummer at openjdk.java.net Tue May 11 19:31:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 11 May 2021 19:31:56 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v4] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 06:35:43 GMT, Mitsuru kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru kariya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3522 From cjplummer at openjdk.java.net Tue May 11 19:38:04 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 11 May 2021 19:38:04 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v23] In-Reply-To: References: Message-ID: <2T6LlZ9PbwPuy5f1_WfMmboNDcHimJ2-dhPvRMH_qlw=.107aa7b8-5d03-47b0-9687-e307f90d30d5@github.com> On Tue, 11 May 2021 03:19:05 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - remove parallel option and dumpheapext command > - Revert "hide the dumpheapext error message" > > This reverts commit 1af0e1e2bfab4f5d079c03ff0cb25067acacdac4. > - ... and 20 more: https://git.openjdk.java.net/jdk/compare/9713152e...5c0863ad heapDumper.hpp needs a copyright update. Otherwise the changes look good. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2261 From sspitsyn at openjdk.java.net Tue May 11 20:27:54 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 11 May 2021 20:27:54 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote: >> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: >> >> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) >> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param >> - Manifestations of Thread::current() become JavaThread::current() >> - THREAD->as_Java_thread() becomes just THREAD >> - THREAD->is_Java_thread() is reworked so that THREAD is "current" >> >> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. >> >> Testing: >> - tiers 1-8 on Linux-x64 >> - all builds in tiers 1-4 >> - tiers 1-3 on all platforms >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback from Serguei Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From mchung at openjdk.java.net Tue May 11 20:52:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 11 May 2021 20:52:59 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> Message-ID: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com> On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix GetModuleTest.java src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53: > 51: return simpleName; > 52: } > 53: // Must be a local class This file should not be changed. It refers to the Java language anonymous class (not VM anonymous class). ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From sspitsyn at openjdk.java.net Tue May 11 21:03:56 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 11 May 2021 21:03:56 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v8] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 02:22:47 GMT, Hamlin Li wrote: >> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine help message. The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2379 From prappo at openjdk.java.net Tue May 11 22:57:24 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 11 May 2021 22:57:24 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v3] In-Reply-To: References: Message-ID: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com> > This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Reverted a previously fixed typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/6eea552e..c8d2c04f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885 From prappo at openjdk.java.net Tue May 11 23:00:55 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 11 May 2021 23:00:55 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v2] In-Reply-To: References: Message-ID: <70URtsH2FCbxLxOfDCVPGXgZN3bMWvC2jeE7AnI6Y3E=.63c0df50-f199-43b2-b36d-29152be9e7c1@github.com> On Wed, 5 May 2021 19:22:11 GMT, Daniel Fuchs wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed more typos > > src/jdk.management.agent/share/classes/sun/management/jmxremote/ConnectorBootstrap.java line 308: > >> 306: public static synchronized JMXConnectorServer initialize() { >> 307: >> 308: // Load new management properties > > Debatable. I guess what was meant here is: > > // Loads a new management Properties instance > > Or maybe a better comment text would be: > > Load and snapshot management properties > > Otherwise LGTM. I've reverted that particular line. ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From dcubed at openjdk.java.net Tue May 11 23:24:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:24:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> Message-ID: On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary "@library /test/lib". > > HI Dan, > > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. > > Cheers, > David @dholmes-ora - Sorry I missed this comment: > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. This test stresses getThreadInfo() and ThreadInfo.getLockOwnerName() as a JavaThread is exiting. Similar to other stress tests that I wrote for M&M in the Thread-SMR project, but this one is targeting getting the lock owner name as the lock owner thread is exiting. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Tue May 11 23:28:53 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:28:53 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v4] In-Reply-To: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> References: <8vtwdpSZT5T3xeXvBMLFtnkPAcTRnqf8KziTzEim43Q=.e791053c-0907-4a32-a111-739f590352da@github.com> Message-ID: <7n0D4JR-B2bxToSWtJ361mu3b_xT5Zfmo9JDsmRISao=.4b15a470-2dd3-460b-884b-3e16925acb87@github.com> On Wed, 28 Apr 2021 13:03:15 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary "@library /test/lib". > > HI Dan, > > Some minor comments, but to be frank I have no idea what this test is actually doing - sorry. > > Cheers, > David @dholmes-ora also sent the comment in email but it didn't seem to show up in this PR: > Hmmm... this is a legacy style/approach that is not necessary any more. > If the test fails it should throw an exception from the main thread and > that will produce a non-zero exit value. I think seeing this legacy style in > new tests will just confuse people. I agree. In particular this legacy style approach with exit_delta == 95 is for VMTestbase tests and this new test is not part of the VMTestbase test suite. I'm fixing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Tue May 11 23:34:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 11 May 2021 23:34:29 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Drop exit_delta and the VMTestbase style of exiting on test failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/bac63a79..771dafee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From sspitsyn at openjdk.java.net Wed May 12 00:46:55 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 12 May 2021 00:46:55 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v3] In-Reply-To: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com> References: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com> Message-ID: On Tue, 11 May 2021 22:57:24 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Reverted a previously fixed typo Hi Pavel, It looks good. Just one nit is to add a dot at the end of this comment: 280 // time. It's OK for now as logic in Agent.java forbids multiple agents Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3885 From mli at openjdk.java.net Wed May 12 01:21:01 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 12 May 2021 01:21:01 GMT Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support parallel [v7] In-Reply-To: References: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com> <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com> <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com> Message-ID: On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> improve jcmd GC.class_histogram to support parallel > > For jmap -histo we have: > > parallel= parallel threads number for heap iteration: > parallel=0 default behavior, use predefined number of threads > parallel=1 disable parallel heap iteration > parallel= use N threads for parallel heap iteration > > It's a bit inconsistent here in that it says , , and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has: > > Options: (options must be specified using the or = syntax) > -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false) > -gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1) > > The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or , or anything like that: > > "Number of parallel threads to use for heap inspection." > "0 (the default) means let the VM determine the number of threads to use. " > "1 means use one thread (disable parallelism). " > "For any other value the VM will try to use the specified number of threads, but might use fewer." > > I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given. Thanks @plummercj @sspitsyn for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From mli at openjdk.java.net Wed May 12 01:21:01 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 12 May 2021 01:21:01 GMT Subject: Integrated: JDK-8261034: improve jcmd GC.class_histogram to support parallel In-Reply-To: References: Message-ID: On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li wrote: > parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too. This pull request has now been integrated. Changeset: 3c47cab6 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/3c47cab6db949b19cfd300139cbdbf81fb521e68 Stats: 98 lines in 4 files changed: 49 ins; 42 del; 7 mod 8261034: improve jcmd GC.class_histogram to support parallel Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/2379 From mchung at openjdk.java.net Wed May 12 02:50:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 12 May 2021 02:50:58 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> Message-ID: On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix GetModuleTest.java I reviewed java.base and took a pass on the test changes. Here are some comments: test/hotspot/jtreg/runtime/HiddenClasses/TestHiddenClassUnloading.java has this comment: +// This is based on test compiler/classUnloading/anonymousClass/TestAnonymousClassUnloading.java This comment can be removed as this test will be removed. A few tests under test/hotspot/jtreg/runtime/HiddenClasses also have similar comment that should be removed. test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/castToGrandparent/Test.java test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/func/classNameInStackTrace/Test.java - I think these tests are already well covered by test/hotspot/jtreg/runtime/HiddenClasses/CastToParentTest.java and test/hotspot/jtreg/runtime/HiddenClasses/HiddenClassStack.java - I suggest to copy the description from the anonloader tests to these hidden class tests test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/share/StressClassLoadingTest.java - test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java is a subset of this test. Should we remove test/hotspot/jtreg/runtime/HiddenClasses/StressClassLoadingTest.java? test/jdk/java/lang/invoke/VMAnonymousClass.java - FYI. I have added a new test to verify hidden class (see JDK-8266925) ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From ysuenaga at openjdk.java.net Wed May 12 05:29:54 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 12 May 2021 05:29:54 GMT Subject: Integrated: 8266531: ZAddress::address() should be removed from SA In-Reply-To: References: Message-ID: <9gabfsfUZib1omZurYMFMnwvU8AJTEYA6xFqXwmvzuM=.7d9fcc35-03cc-41b7-9518-b308a5e6ba01@github.com> On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga wrote: > `ZAddress::address()` has been removed since [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA has not followed it. Thus some SA tests would fail with ZGC. > After this change, more than half of jtreg tests which are listed in ProblemList-zgc.txt pass on Linux x64 with -vmoption:-XX:+UseZGC. Please see the change of ProblemList-zgc.txt what test can be resolved. This pull request has now been integrated. Changeset: 476994aa Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/476994aa373ac95e73e672b7cc463c95e96509dc Stats: 59 lines in 8 files changed: 13 ins; 34 del; 12 mod 8266531: ZAddress::address() should be removed from SA Reviewed-by: cjplummer, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/3868 From rehn at openjdk.java.net Wed May 12 06:06:01 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 06:06:01 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:02:44 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn 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 two additional commits since the last revision: >> >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 320: > >> 318: // JavaThreads will enter here with state _thread_in_native. >> 319: void JvmtiRawMonitor::raw_enter(Thread* self) { >> 320: // TODO Atomic::load on _owner field > > Why is this still a TODO? We have ~15 plain loads of _owner, I thought it would be nice to fix all at the same time and I did not want to clobber this with that also. I can do a follow-up and change them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 12 08:04:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:04:55 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 17:08:30 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn 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 two additional commits since the last revision: >> >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 42: > >> 40: // Important note: >> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM >> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint > > nit typo: s/e.g./e.g.,/ > nit typo: s/tranisition/transition/ Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 43: > >> 41: // Raw monitors can be used in callbacks which happen during safepoint by the VM >> 42: // thread (e.g. heapRootCallback). This means we may not tranisition/safepoint >> 43: // poll in many cases, else the agent JavaThread can deadlock with VM thread, > > nit typo: s/VM thread/the VM thread/ Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > >> 50: // native for all operations. However we need to honor suspend request, not >> 51: // entering a monitor if suspended, and check for interrupts. Honoring suspened >> 52: // and reading interrupt flag must be done from VM state (a safepoint unsafe > > nit typo: s/suspend request/a suspend request/ > nit typo: s/Honoring suspened/Honoring a suspend request/ > nit typo: s/interrupt flag/the interrupt flag/ > (You'll probably want to reformat the changed lines a bit.) Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 206: > >> 204: ~ThreadInVMfromNative() { >> 205: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); >> 206: _thread->set_thread_state(_thread_in_native); > > You're losing the assertion that we're transitioning from > `_thread_in_vm` to `_thread_in_native` here. Although, > the constructor did verify that we were in `_thread_in_native` > when we transitioned to `_thread_in_vm` so at least the > first half is still verified. > > Can you an assertion that we're in `_thread_in_vm` here? Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _om_exit; > > Instead of `_om_exit` maybe this should be more generic? > Perhaps `_om_op_done` or something like that? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 12 08:04:47 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:04:47 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixes for Dan ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/07ddf393..1c6448e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=01-02 Stats: 16 lines in 4 files changed: 3 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 12 08:08:55 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 08:08:55 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 19:08:46 GMT, Daniel D. Daugherty wrote: > Thumbs up on the over all logic. I only have minor nits and suggestions. Thank you! > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > >> 46: // The rules are: >> 47: // - We must never safepoint poll if raw monitor is owned. >> 48: // - We may safepoint poll before it is owned and after it have been released. > > nit typo: s/have been/has been/ Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: > >> 228: }; >> 229: >> 230: template > > When you mentioned doing this with templates, I was having > nightmares, but this one is not bad at all... :) > src/hotspot/share/runtime/objectMonitor.cpp line 313: > >> 311: if (current->is_suspended()) { >> 312: _om->_recursions = 0; >> 313: _om->_succ = NULL; > > Please add a comment after this line: > // Don't need a full fence after clearing successor here because of the call to exit(). Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rrich at openjdk.java.net Wed May 12 08:31:13 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 08:31:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rrich at openjdk.java.net Wed May 12 08:31:13 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 08:31:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:24 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 230: >> >>> 228: }; >>> 229: >>> 230: template >> >> When you mentioned doing this with templates, I was having >> nightmares, but this one is not bad at all... > > :) Any reason why you don't use a ThreadClosure instead of the template parameter. I reckon it cannot be performance since it is only used on the slow path. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From prappo at openjdk.java.net Wed May 12 09:14:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 12 May 2021 09:14:53 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v4] In-Reply-To: References: Message-ID: > This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Added missing full stops ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3885/files - new: https://git.openjdk.java.net/jdk/pull/3885/files/c8d2c04f..7a834b3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3885&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3885/head:pull/3885 PR: https://git.openjdk.java.net/jdk/pull/3885 From prappo at openjdk.java.net Wed May 12 09:18:54 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 12 May 2021 09:18:54 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v3] In-Reply-To: References: <-vEUXKnK4Hx08RxoJZ6znhlblhrIgoslG7odDTh27Ns=.7eb65699-6068-4f09-8d14-5a9455b5a854@github.com> Message-ID: On Wed, 12 May 2021 00:43:59 GMT, Serguei Spitsyn wrote: > Just one nit is to add a dot at the end of this comment: > 280 // time. It's OK for now as logic in Agent.java forbids multiple agents I added two full stops: one for each unterminated sentence in that inline comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From sspitsyn at openjdk.java.net Wed May 12 09:33:52 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 12 May 2021 09:33:52 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v4] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 09:14:53 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Added missing full stops Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From dfuchs at openjdk.java.net Wed May 12 09:33:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 12 May 2021 09:33:53 GMT Subject: RFR: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap [v4] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 09:14:53 GMT, Pavel Rappo wrote: >> This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. >> >> Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: >> >> 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` >> 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Added missing full stops Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From rehn at openjdk.java.net Wed May 12 10:56:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 12 May 2021 10:56:15 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > Hi Robbin, > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > Thanks, Richard. Hi Richard, I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. Regarding ThreadClosure, we could use it, maybe that is preferable?! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From prappo at openjdk.java.net Wed May 12 11:01:16 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 12 May 2021 11:01:16 GMT Subject: Integrated: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap In-Reply-To: References: Message-ID: On Wed, 5 May 2021 15:59:43 GMT, Pavel Rappo wrote: > This fixes two javadoc tag references and several typos. References are fixed by removing whitespace before the opening `(`. That whitespace caused the opening `(` and the rest of the reference to be parsed as a link label. > > Since we are here, I think this class could also benefit from using modern APIs. This should be done in a separate PR though. For example: > > 1. Numerous instances of `Boolean.valueOf( ).booleanValue()` could be changed to `Boolean.parseBoolean( )` > 2. `throw (IllegalArgumentException) new IllegalArgumentException(msg).initCause(e);` could be changed to `throw new IllegalArgumentException(msg, e);` This pull request has now been integrated. Changeset: 4727187f Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/4727187f86d18d34bd79cf93a74ff4a6515c662e Stats: 12 lines in 1 file changed: 0 ins; 1 del; 11 mod 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap Reviewed-by: dfuchs, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3885 From lzang at openjdk.java.net Wed May 12 11:10:37 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:10:37 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: References: Message-ID: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into pd - update copyright info - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - Merge branch 'master' into par-dump - Typo fix - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=23 Stats: 841 lines in 5 files changed: 653 ins; 61 del; 127 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Wed May 12 11:11:39 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:11:39 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10] In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into s-fix - fix typo in comments - Merge branch 'master' into s-fix - Merge branch 'master' - Merge branch 'master' into sf - rename writeThrough to unbufferedMode and code refine - fix typo in comments - Merge branch 'master' into sf - Revert "reduce memory consumption" This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e. - reduce memory consumption - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8db72dde...6fde07bd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2803/files - new: https://git.openjdk.java.net/jdk/pull/2803/files/67f6d985..6fde07bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=08-09 Stats: 4888 lines in 218 files changed: 1525 ins; 782 del; 2581 mod Patch: https://git.openjdk.java.net/jdk/pull/2803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803 PR: https://git.openjdk.java.net/jdk/pull/2803 From lzang at openjdk.java.net Wed May 12 11:14:55 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:14:55 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Dear Ralf(@schmelter-sap), I am not a reviewer, just want to state that this change looks good to me and also helpful. I have encountered an issue that happened 2 times among 100 times try when testing #2261. And after applied this change, it works normally for another 100 times test. Just FYI. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From lzang at openjdk.java.net Wed May 12 11:17:57 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 12 May 2021 11:17:57 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> References: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> Message-ID: <_zH7zhSHNVXccz-n8ejwCp-_QIxvB5ICu_ieahs7ui4=.b732dbcb-aaaf-40c3-aa09-f3fe8fe720ef@github.com> On Wed, 12 May 2021 11:10:37 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f Dear Chris, Thanks a lot for reviewing. I did more stress tests recently and found an issue that seems could be fixed by #3628, I am still verifying it. Will update when I confirm it. Just FYI. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From rrich at openjdk.java.net Wed May 12 12:35:27 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 12:35:27 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <909VtnsgD4R5wqUITLJD9R_4jDxnhLSLL7DyBaah4Ug=.bff780ad-86d9-4d99-8a98-3314d806212d@github.com> On Wed, 12 May 2021 10:53:21 GMT, Robbin Ehn wrote: > > > > Hi Robbin, > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > Thanks, Richard. > > Hi Richard, > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. Yes, I'd think so too. > Regarding ThreadClosure, we could use it, maybe that is preferable?! Personally I'd prefer it but I'm fine with the current version too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Wed May 12 13:00:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 May 2021 23:00:03 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <6d44b14a-875f-3658-970d-2604c0ebf1a5@oracle.com> On 12/05/2021 8:56 pm, Robbin Ehn wrote: > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > >> Hi Robbin, >> >> I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. >> >> Thanks, Richard. > > Hi Richard, > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. > > Regarding ThreadClosure, we could use it, maybe that is preferable?! Isn't a ThreadClosure for applying an operation to a set of threads? That is not what we are doing here. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From rrich at openjdk.java.net Wed May 12 15:31:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 15:31:11 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Hi Ralf, your change looks good to me. Thanks for fixing, Richard. src/hotspot/share/services/heapDumperCompression.cpp line 262: > 260: } > 261: > 262: void CompressionBackend::thread_loop() { You could simplify `CompressionBackend::thread_loop()` further: void CompressionBackend::thread_loop() { { MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); _nr_of_threads++; } WriteWork* work = get_work(); while (work != NULL) { do_compress(work); finish_work(work); work = get_work(); } MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); _nr_of_threads--; assert(_nr_of_threads >= 0, "Too many threads finished"); ml.notify_all(); } ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From rrich at openjdk.java.net Wed May 12 15:31:12 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 12 May 2021 15:31:12 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> On Wed, 12 May 2021 14:37:14 GMT, Richard Reingruber wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > src/hotspot/share/services/heapDumperCompression.cpp line 262: > >> 260: } >> 261: >> 262: void CompressionBackend::thread_loop() { > > You could simplify `CompressionBackend::thread_loop()` further: > > > void CompressionBackend::thread_loop() { > { > MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); > _nr_of_threads++; > } > > WriteWork* work = get_work(); > while (work != NULL) { > do_compress(work); > finish_work(work); > work = get_work(); > } > > MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); > _nr_of_threads--; > assert(_nr_of_threads >= 0, "Too many threads finished"); > ml.notify_all(); > } BTW: why is `ml.notify_all()` in line 275 needed at all? ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From hseigel at openjdk.java.net Wed May 12 16:10:25 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 12 May 2021 16:10:25 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> Message-ID: On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix GetModuleTest.java Thanks Alan, Ioi, and Mandy for looking at this. The latest changes should address the issues that you found. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Wed May 12 16:10:24 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 12 May 2021 16:10:24 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: test changes and small fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3974/files - new: https://git.openjdk.java.net/jdk/pull/3974/files/874a1603..5246dd76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=02-03 Stats: 286 lines in 10 files changed: 22 ins; 256 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Wed May 12 16:10:27 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 12 May 2021 16:10:27 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> <6jFp2B7imcUETfAlhzQUDtp45nwnPauD7rcSfqG4CI8=.39e2a9ab-42ec-4633-9bfc-82a327ed2564@github.com> Message-ID: On Tue, 11 May 2021 20:49:46 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix GetModuleTest.java > > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 53: > >> 51: return simpleName; >> 52: } >> 53: // Must be a local class > > This file should not be changed. It refers to the Java language anonymous class (not VM anonymous class). Changes have been restored. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Wed May 12 16:10:26 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 12 May 2021 16:10:26 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v3] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <7O7INx2lES-Pa_hg-Li7nLn6XU6Y3n9zLgncPxR26v0=.73da1685-2d3c-415c-931a-053c00394c73@github.com> Message-ID: <6vXfHjNzHSk46muMlntg2ZqE1OSmHx0eg08V-3AqIvc=.2dbd90d5-453a-4447-abfd-9aebfff9143d@github.com> On Tue, 11 May 2021 17:07:35 GMT, Ioi Lam wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix GetModuleTest.java > > src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65: > >> 63: // so when handling the java mirror for the class we need to make sure its class >> 64: // loader data is claimed, this is done by calling do_cld explicitly. >> 65: // For non-string hidden classes the call to do_cld is made when the class > > Typo: non-strong fixed, thanks for finding this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From rschmelter at openjdk.java.net Wed May 12 17:55:57 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Wed, 12 May 2021 17:55:57 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> <5CPIAlmMc6p7oVHAaUlLz7_0CZQesWLFs0T0hXWZ81o=.a2fcf555-1d56-4339-bfba-a6a1268c789f@github.com> Message-ID: On Wed, 12 May 2021 15:22:52 GMT, Richard Reingruber wrote: >> src/hotspot/share/services/heapDumperCompression.cpp line 262: >> >>> 260: } >>> 261: >>> 262: void CompressionBackend::thread_loop() { >> >> You could simplify `CompressionBackend::thread_loop()` further: >> >> >> void CompressionBackend::thread_loop() { >> { >> MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); >> _nr_of_threads++; >> } >> >> WriteWork* work = get_work(); >> while (work != NULL) { >> do_compress(work); >> finish_work(work); >> work = get_work(); >> } >> >> MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag); >> _nr_of_threads--; >> assert(_nr_of_threads >= 0, "Too many threads finished"); >> ml.notify_all(); >> } > > BTW: why is `ml.notify_all()` in line 275 needed at all? Hi, thanks for the review Lin and Richard. The notify_all() is indeed not needed anymore. It was originally needed when the worker threads were newly created threads and we had to wait for them to finish at the end of the dump operation. But since we now use the GC work gang, this can be removed. I will update the PR with your suggestions. Best regards, Ralf ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From cjplummer at openjdk.java.net Wed May 12 18:07:57 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 12 May 2021 18:07:57 GMT Subject: RFR: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back on ZGC problem list due to JDK-8267045 Message-ID: [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added. ------------- Commit messages: - ProblemList serviceability/sa/TestJmapCoreMetaspace.java Changes: https://git.openjdk.java.net/jdk/pull/4002/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4002&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267047 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4002.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4002/head:pull/4002 PR: https://git.openjdk.java.net/jdk/pull/4002 From dcubed at openjdk.java.net Wed May 12 18:51:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 12 May 2021 18:51:56 GMT Subject: RFR: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back on ZGC problem list due to JDK-8267045 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:00:56 GMT, Chris Plummer wrote: > [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4002 From cjplummer at openjdk.java.net Wed May 12 21:05:11 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 12 May 2021 21:05:11 GMT Subject: Integrated: 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back on ZGC problem list due to JDK-8267045 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 18:00:56 GMT, Chris Plummer wrote: > [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK)-8267045 removed this test from the ZGC problem list, but it still fails, so it needs to be re-added. This pull request has now been integrated. Changeset: 2568d181 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/2568d181a778add4837bb0eada8c5f4a137d4560 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8267047: Put serviceability/sa/TestJmapCoreMetaspace.java back on ZGC problem list due to JDK-8267045 Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4002 From mchung at openjdk.java.net Wed May 12 22:34:55 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 12 May 2021 22:34:55 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > test changes and small fixes Overall looks good to me. src/hotspot/share/classfile/classLoaderData.cpp line 299: > 297: } > 298: > 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive `s/Weak/Non-strong/` test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39: > 37: import jdk.test.lib.compiler.InMemoryJavaCompiler; > 38: > 39: public class StressHiddenClasses { Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it. I think this can be removed as JDK-8265694 suggests. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3974 From cjplummer at openjdk.java.net Wed May 12 22:44:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 12 May 2021 22:44:59 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v24] In-Reply-To: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> References: <0Ro-Q_NsZf4bDvLwxr8GG3h81XYiXlczKBcJa16hSG8=.aa0cd14e-1974-462f-aee1-d081bb1ebc3b@github.com> Message-ID: On Wed, 12 May 2021 11:10:37 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - Merge branch 'master' into par-dump > - Typo fix > - ... and 22 more: https://git.openjdk.java.net/jdk/compare/4727187f...6d8e944f Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From cjplummer at openjdk.java.net Wed May 12 23:05:52 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 12 May 2021 23:05:52 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> Message-ID: <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> On Tue, 11 May 2021 01:34:16 GMT, Yasumasa Suenaga wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 93: >> >>> 91: >>> 92: public static Remote lookup(String debugServerID) throws DebuggerException { >>> 93: // debugServerID follows the pattern [unique_id@]host[:port][/prefix] >> >> It's a bit unclear to me why we need both a "unique_id" and a "prefix". I understand that the SA already append the two, and that previously the prefix was a constant, but I don't see why the user would ever need to set the "prefix" when they can always specify a "unique_id" that is truly unique. What is the use case for this? > > "prefix" is similar to "unique_id" as you said, but it is useful to group debugees. > > For example, the host runs 2 container pods as following: > > * Pod A > * Container 1 > * Container 2 > * Container 3 > * Pod B > * Container 1 > * Container 2 > * Container 3 > > If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1". > However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand. Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL. I'm not saying that we need to explain how the `--connect [@][:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `` and `/prefix`. Otherwise no one is really going to understand how/why to use it. Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be: [[prefix/]unique_id@]host[:port] ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From kvn at openjdk.java.net Thu May 13 03:29:57 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 13 May 2021 03:29:57 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v2] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote: >> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: >> >> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) >> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param >> - Manifestations of Thread::current() become JavaThread::current() >> - THREAD->as_Java_thread() becomes just THREAD >> - THREAD->is_Java_thread() is reworked so that THREAD is "current" >> >> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. >> >> Testing: >> - tiers 1-8 on Linux-x64 >> - all builds in tiers 1-4 >> - tiers 1-3 on all platforms >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback from Serguei Compiler related changes seems fine. @dougxc, note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3877 From david.holmes at oracle.com Thu May 13 03:59:50 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 May 2021 13:59:50 +1000 Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v2] In-Reply-To: References: Message-ID: <3a458466-6e48-309b-e78d-146ab4edd9d5@oracle.com> On 13/05/2021 1:29 pm, Vladimir Kozlov wrote: > On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote: >> >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback from Serguei > > Compiler related changes seems fine. > @dougxc, note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV. Thanks for the review Vladimir! cc'ing Doug in case the @-notification doesn't work. David > ------------- > > Marked as reviewed by kvn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3877 > From dholmes at openjdk.java.net Thu May 13 04:59:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 04:59:11 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v3] In-Reply-To: References: Message-ID: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com> > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Update after merge with master - Merge branch 'master' into 8252685-JavaThread - Review feedback from Serguei - Merge - 8252685: APIs that require JavaThread should take JavaThread arguments ------------- Changes: https://git.openjdk.java.net/jdk/pull/3877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=02 Stats: 537 lines in 121 files changed: 14 ins; 30 del; 493 mod Patch: https://git.openjdk.java.net/jdk/pull/3877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877 PR: https://git.openjdk.java.net/jdk/pull/3877 From ysuenaga at openjdk.java.net Thu May 13 05:59:51 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 13 May 2021 05:59:51 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> Message-ID: On Wed, 12 May 2021 23:03:04 GMT, Chris Plummer wrote: >> "prefix" is similar to "unique_id" as you said, but it is useful to group debugees. >> >> For example, the host runs 2 container pods as following: >> >> * Pod A >> * Container 1 >> * Container 2 >> * Container 3 >> * Pod B >> * Container 1 >> * Container 2 >> * Container 3 >> >> If we want to compare 2 pods with jhsdb, we can set ID like "A-1", "B-1". >> However, if the prefix is supported on jhsdb, we can set ID and prefix like "1 at localhost/A", "1 at localhost/B". I think it is easy to understand. > > Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL. > > I'm not saying that we need to explain how the `--connect [@][:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `` and `/prefix`. Otherwise no one is really going to understand how/why to use it. > > Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be: > > [[prefix/]unique_id@]host[:port] Finally, all parameters will be transformed to `//host[:port]/['_']`. `--prefix` and `id` affect to RMI object name to be precise. So ID is object name, then the prefix will be added to it. Based on them, how about this? --prefix Set the prefix to add to debug server instance name. I understand is is odd the value is added to the tail even if it is named "prefix". Both `prefix` and `id` are optional, so we can specify `prefix` only, then `prefix/@host` is strange for me. How about this pattern? Use ":" instead of "/" like a URL. [prefix:][unique_id@]host[:port] I thought to give new name instead of "prefix", but I give up because I have not good idea and would be inconsistent system property. (`sun.jvm.hotspot.rmi.serverNamePrefix`) ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From dholmes at openjdk.java.net Thu May 13 06:07:00 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 06:07:00 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, Sorry for the delay in getting through this. Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. Thanks, David src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > 46: // The rules are: > 47: // - We must never safepoint poll if raw monitor is owned. > 48: // - We may safepoint poll before it is owned and after it has been released. I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96: > 94: protected: > 95: JvmtiRawMonitor* _rm; > 96: bool _rm_exit; If this signifies the monitor exited then please name it `_rm_exited`. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207: > 205: assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state"); > 206: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); > 207: _thread->set_thread_state(_thread_in_native); After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: > 275: class ThreadBlockInVM { > 276: InFlightMutexRelease _ifmr; > 277: ThreadBlockInVMPreprocess _tbivmpp; Why delegate to the TBIVMPP instead of extending it? src/hotspot/share/runtime/objectMonitor.cpp line 435: > 433: EnterI(current); > 434: } > 435: if (!eos.om_op_done()) { I find this API too generic. I'd much rather see: if (!eos.exited()) { assert ... break; } src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _om_op_done; Please rename to _exited - we know what the "op" is so no need to use generic terminology. src/hotspot/share/runtime/objectMonitor.hpp line 313: > 311: ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {} > 312: void operator()(JavaThread* current); > 313: bool om_op_done() { return _om_op_done; } please rename to exited() src/hotspot/share/runtime/objectMonitor.hpp line 315: > 313: bool om_op_done() { return _om_op_done; } > 314: }; > 315: class ClearSuccOnSuspend : public ExitOnSuspend { I don't see why there is any relationship between these two. You don't clear-succ and exit. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From alanb at openjdk.java.net Thu May 13 06:24:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 13 May 2021 06:24:54 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: <26yxlZkGUBDT2wTKQUS9koA7PZPYojY23wJvl7aTAWE=.6ac4247e-b13f-4ed1-b603-6ff1b09f526b@github.com> On Tue, 11 May 2021 14:11:22 GMT, Harold Seigel wrote: >> Can you check test/jdkjava/lang/Class/attributes/ClassAttributesTest.java? It may minimally need a comment to be updated. That's the only additional test that I could find in test/jdk. > > Hi Alan, > Thanks for find this. I removed the unneeded imports and @modules from GetModulesTest.java and updated the comment in ClassAttributesTest.java. > Thanks, Harold Thanks for fixing up these tests, I didn't spot any more in the test/jdk tree. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From alanb at openjdk.java.net Thu May 13 06:24:54 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 13 May 2021 06:24:54 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > test changes and small fixes Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From dholmes at openjdk.java.net Thu May 13 07:27:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 07:27:56 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > test changes and small fixes Hi Harold, Big change! :) This looks good. All the removals of references to unsafe_anonymous were easy enough to follow. I didn't realize that cp patching and psuedo-strings were only related to VM anonymous. It is good to see all that code go as well (but hard to see if you got it all :) ). But as per comment below are we sure psuedo-strings can't be used elsewhere? Thanks, David src/hotspot/share/oops/constantPool.hpp line 493: > 491: // object into a CONSTANT_String entry of an unsafe anonymous class. > 492: // Methods internally created for method handles may also > 493: // use pseudo-strings to link themselves to related metaobjects. Is this comment wrong? Are psuedo-strings not used by anything now? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3974 From dholmes at openjdk.java.net Thu May 13 08:14:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 13 May 2021 08:14:55 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Drop exit_delta and the VMTestbase style of exiting on test failure. Hi Dan, Seems fine. Thanks for the updates. The proof of a test is in its execution :) David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3478 From hseigel at openjdk.java.net Thu May 13 12:31:44 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 12:31:44 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5] In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com> > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: fix Weak hidden comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3974/files - new: https://git.openjdk.java.net/jdk/pull/3974/files/5246dd76..38675761 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3974.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Thu May 13 12:31:48 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 12:31:48 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> test changes and small fixes > > src/hotspot/share/classfile/classLoaderData.cpp line 299: > >> 297: } >> 298: >> 299: // Weak hidden classes have their own ClassLoaderData that is marked to keep alive > > `s/Weak/Non-strong/` fixed. thanks for finding it. > test/hotspot/jtreg/runtime/HiddenClasses/StressHiddenClasses.java line 39: > >> 37: import jdk.test.lib.compiler.InMemoryJavaCompiler; >> 38: >> 39: public class StressHiddenClasses { > > Since `StressClassLoadingTest` is revised to test hidden class, this test is a subset of it. > I think this can be removed as JDK-8265694 suggests. Thanks Mandy. I will remove the test as the fix for JDK-8265694 after this change is pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Thu May 13 12:38:01 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 12:38:01 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5] In-Reply-To: References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Thu, 13 May 2021 07:19:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> fix Weak hidden comment > > src/hotspot/share/oops/constantPool.hpp line 493: > >> 491: // object into a CONSTANT_String entry of an unsafe anonymous class. >> 492: // Methods internally created for method handles may also >> 493: // use pseudo-strings to link themselves to related metaobjects. > > Is this comment wrong? Are psuedo-strings not used by anything now? Thanks for looking at this. I discussed pseudo strings with Coleen and we didn't find any use of them besides unsafe.DefineAnonymousClass. ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Thu May 13 12:50:40 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 12:50:40 GMT Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v5] In-Reply-To: <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <0WaW5NgnyLVdSeN0HAKyHBve4zFSBH_mbLGCa-EqzAM=.c7f0ca4e-106e-4614-83c5-07ee7c1d8c31@github.com> Message-ID: On Thu, 13 May 2021 12:31:44 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > fix Weak hidden comment Thanks Ioi, Alan, Mandy, and David for reviewing this big change! ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From hseigel at openjdk.java.net Thu May 13 12:50:41 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 13 May 2021 12:50:41 GMT Subject: Integrated: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> Message-ID: On Tue, 11 May 2021 12:50:31 GMT, Harold Seigel wrote: > Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: e14b0268 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/e14b0268411bba8eb01bf6c477cc8743a53ffd1c Stats: 3754 lines in 122 files changed: 75 ins; 3426 del; 253 mod 8243287: Removal of Unsafe::defineAnonymousClass Reviewed-by: iklam, mchung, alanb, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3974 From dnsimon at openjdk.java.net Thu May 13 13:20:55 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 13 May 2021 13:20:55 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v2] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 03:26:50 GMT, Vladimir Kozlov wrote: > Compiler related changes seems fine. > @dougxc, note that jvmci is affected. It looks reasonable for me but you may need to check if it is correct from libgraal POV. I tried to test this patch against GraalVM but am blocked due to `jdk.internal.vm.compiler` [no longer being upgradeable](https://bugs.openjdk.java.net/browse/JDK-8265091?focusedCommentId=14417587&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14417587). ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From dcubed at openjdk.java.net Thu May 13 15:40:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 13 May 2021 15:40:55 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 08:12:22 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop exit_delta and the VMTestbase style of exiting on test failure. > > Hi Dan, > > Seems fine. Thanks for the updates. > > The proof of a test is in its execution :) > > David @dholmes-ora - Thanks for the re-review. My Mach5 Tier[1-7] testing for an earlier version of the test is documented in the bug report. @plummercj - Are you still planning to review this new test? ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From iklam at openjdk.java.net Thu May 13 17:03:08 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 13 May 2021 17:03:08 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v3] In-Reply-To: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com> References: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com> Message-ID: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com> On Thu, 13 May 2021 04:59:11 GMT, David Holmes wrote: >> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: >> >> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) >> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param >> - Manifestations of Thread::current() become JavaThread::current() >> - THREAD->as_Java_thread() becomes just THREAD >> - THREAD->is_Java_thread() is reworked so that THREAD is "current" >> >> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. >> >> Testing: >> - tiers 1-8 on Linux-x64 >> - all builds in tiers 1-4 >> - tiers 1-3 on all platforms >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Update after merge with master > - Merge branch 'master' into 8252685-JavaThread > - Review feedback from Serguei > - Merge > - 8252685: APIs that require JavaThread should take JavaThread arguments LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3877 From cjplummer at openjdk.java.net Thu May 13 18:03:59 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 13 May 2021 18:03:59 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 23:21:51 GMT, Chris Plummer wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. > @plummercj - Are you still planning to review this new test? Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Thu May 13 18:30:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 13 May 2021 18:30:56 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> Message-ID: On Thu, 13 May 2021 05:56:00 GMT, Yasumasa Suenaga wrote: >> Ok, this explanation seems reasonable, but is not something that is really conveyed with the the name `--prefix` or with the help "Sets the prefix to distinguish SA debugee". We are at the same giving too much and too little info. Too much in that we are saying that it is a prefix of some sort, which then leads to that fact that we don't explain how it is used in the RMI URL. >> >> I'm not saying that we need to explain how the `--connect [@][:registryport][/prefix]` option is converted into an RMI URL (although perhaps we should), but it seems we at least need to describe the relation between `` and `/prefix`. Otherwise no one is really going to understand how/why to use it. >> >> Also, having the prefix at the end of the "serverID" string seems odd. Maybe it should be: >> >> [[prefix/]unique_id@]host[:port] > > Finally, all parameters will be transformed to `//host[:port]/['_']`. > `--prefix` and `id` affect to RMI object name to be precise. So ID is object name, then the prefix will be added to it. > > Based on them, how about this? > > > --prefix Set the prefix to add to debug server instance name. > > > I understand is is odd the value is added to the tail even if it is named "prefix". > Both `prefix` and `id` are optional, so we can specify `prefix` only, then `prefix/@host` is strange for me. > > How about this pattern? Use ":" instead of "/" like a URL. > > > [prefix:][unique_id@]host[:port] > > > I thought to give new name instead of "prefix", but I give up because I have not good idea and would be inconsistent system property. (`sun.jvm.hotspot.rmi.serverNamePrefix`) I think this is better, but I think better help output is needed. `prefix` has a default and `unique_id` does not. I think both of these need to be mentioned in the help output. Also, if `unique_id` is not specified, then the value of `prefix` is the name of the RMI object, which seems a bit odd because it is suppose to be a prefix to a name, not the entire name. I think maybe the property name of `sun.jvm.hotspot.rmi.serverNamePrefix` was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it `sun.jvm.hotspot.rmi.serverName`, and then appending an optional `unique_id` to it would make more sense. What if instead of `prefix` you used `servername` and possibly also rename `sun.jvm.hotspot.rmi.serverNamePrefix` to `sun.jvm.hotspot.rmi.serverName`, but also keep legacy support in case someone is already using `sun.jvm.hotspot.rmi.serverNamePrefix` and decides to set it? ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From mandy.chung at oracle.com Thu May 13 18:50:22 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 May 2021 11:50:22 -0700 Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> Message-ID: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com> I did a search on java.base and the tests on `String::indexOf` and `String::contains` of a slash and don't spot any such test.? The JDK has no use of VM anonymous class.?? If the test is trying to determine if it's lambda proxy class, it should be converted to call `Class::isHidden` but testing of the class name containing a slash is still valid (I haven't found any of such test though). Mandy On 5/11/21 6:20 AM, Brian Goetz wrote: > There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?. Did you do a search for these idioms too, which are now dead tests? > > Sent from my iPad > >> On May 11, 2021, at 8:59 AM, Harold Seigel wrote: >> >> ?Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >> >> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >> >> Thanks, Harold >> >> ------------- >> >> Commit messages: >> - 8243287: Removal of Unsafe::defineAnonymousClass >> >> Changes: https://git.openjdk.java.net/jdk/pull/3974/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8243287 >> Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod >> Patch: https://git.openjdk.java.net/jdk/pull/3974.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/3974/head:pull/3974 >> >> PR: https://git.openjdk.java.net/jdk/pull/3974 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu May 13 19:03:09 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 May 2021 15:03:09 -0400 Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com> Message-ID: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com> Thanks for checking.? I thought I remembered something like this somewhere, but it may be that you already fixed such tests when you did hidden classes?? In any case, seems like we're all good now. Cheers, -Brian On 5/13/2021 2:50 PM, Mandy Chung wrote: > I did a search on java.base and the tests on `String::indexOf` and > `String::contains` of a slash and don't spot any such test.? The JDK > has no use of VM anonymous class. If the test is trying to determine > if it's lambda proxy class, it should be converted to call > `Class::isHidden` but testing of the class name containing a slash is > still valid (I haven't found any of such test though). > > Mandy > > On 5/11/21 6:20 AM, Brian Goetz wrote: >> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?. Did you do a search for these idioms too, which are now dead tests? >> >> Sent from my iPad >> >>> On May 11, 2021, at 8:59 AM, Harold Seigel wrote: >>> >>> ?Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >>> >>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >>> >>> Thanks, Harold >>> >>> ------------- >>> >>> Commit messages: >>> - 8243287: Removal of Unsafe::defineAnonymousClass >>> >>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files >>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8243287 >>> Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod >>> Patch:https://git.openjdk.java.net/jdk/pull/3974.diff >>> Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/3974/head:pull/3974 >>> >>> PR:https://git.openjdk.java.net/jdk/pull/3974 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjplummer at openjdk.java.net Thu May 13 20:34:44 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 13 May 2021 20:34:44 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Wed, 12 May 2021 11:11:39 GMT, Lin Zang wrote: >> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'master' into s-fix > - fix typo in comments > - Merge branch 'master' into s-fix > - Merge branch 'master' > - Merge branch 'master' into sf > - rename writeThrough to unbufferedMode and code refine > - fix typo in comments > - Merge branch 'master' into sf > - Revert "reduce memory consumption" > > This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e. > - reduce memory consumption > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7dae89e1...6fde07bd Overall looks good. I just have one question and a couple minor comment suggestions. Also, can you do the same extra testing that you did for #2261 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1510: > 1508: */ > 1509: private boolean shouldFlush() { > 1510: // unbuffered mode always flush data. "flushes data" src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528: > 1526: } > 1527: writeInteger(0); > 1528: writeInteger(size); You've added `writeInteger(size)` here, but I'm not sure where this used to be done. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1577: > 1575: private boolean segmentMode; > 1576: private boolean allowSegmented; > 1577: // Writes data directly to underlying stream, don't use internal buffer. It should be "Write data". I noticed you recently changed it to "Writes", but I'm not sure why. Also, make this two sentences rather than using a comma. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2803 From mandy.chung at oracle.com Thu May 13 20:37:34 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 May 2021 13:37:34 -0700 Subject: RFR: 8243287: Removal of Unsafe::defineAnonymousClass In-Reply-To: <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com> References: <81SLN8H3A0I9s4H66BAvH50A8Qiw2ItvrhzkOD3WRXc=.6e763e4c-6a45-455b-8e2e-03fb57759b78@github.com> <1D7A5834-1DCB-4AC7-95EF-5E791F362086@oracle.com> <79105f52-d0df-b479-1c6c-f0cbf793a624@oracle.com> <8a888235-84e9-eb72-c709-9060f0862bc1@oracle.com> Message-ID: Maybe you were thinking `jdk.internal.reflect.ReflectUtil::isVMAnonymousClass` that is now removed by this patch [1]. [1] https://github.com/openjdk/jdk/pull/3974/files#diff-1af3026a3b4942af3ebe6a4df02f8952fb9d51bf93336a2f7f93ce175d047574 On 5/13/21 12:03 PM, Brian Goetz wrote: > Thanks for checking.? I thought I remembered something like this > somewhere, but it may be that you already fixed such tests when you > did hidden classes?? In any case, seems like we're all good now. > > Cheers, > -Brian > > On 5/13/2021 2:50 PM, Mandy Chung wrote: >> I did a search on java.base and the tests on `String::indexOf` and >> `String::contains` of a slash and don't spot any such test.? The JDK >> has no use of VM anonymous class.?? If the test is trying to >> determine if it's lambda proxy class, it should be converted to call >> `Class::isHidden` but testing of the class name containing a slash is >> still valid (I haven't found any of such test though). >> >> Mandy >> >> On 5/11/21 6:20 AM, Brian Goetz wrote: >>> There may be some JDK code that checks for anon classes by comparing the name to see if it contains a slash, especially tests, but which don?t say ?anonymous?. Did you do a search for these idioms too, which are now dead tests? >>> >>> Sent from my iPad >>> >>>> On May 11, 2021, at 8:59 AM, Harold Seigel wrote: >>>> >>>> ?Please review this large change to remove Unsafe::defineAnonymousClass(). The change removes dAC relevant code and changes a lot of tests. Many of the changed tests need renaming. I hope to do this in a follow up RFE. Some of the tests were modified to use hidden classes, others were deleted because either similar hidden classes tests already exist or they tested dAC specific functionality, such as host classes. >>>> >>>> This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-7 on Linux x64. >>>> >>>> Thanks, Harold >>>> >>>> ------------- >>>> >>>> Commit messages: >>>> - 8243287: Removal of Unsafe::defineAnonymousClass >>>> >>>> Changes:https://git.openjdk.java.net/jdk/pull/3974/files >>>> Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=3974&range=00 >>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8243287 >>>> Stats: 3516 lines in 116 files changed: 69 ins; 3181 del; 266 mod >>>> Patch:https://git.openjdk.java.net/jdk/pull/3974.diff >>>> Fetch: git fetchhttps://git.openjdk.java.net/jdk pull/3974/head:pull/3974 >>>> >>>> PR:https://git.openjdk.java.net/jdk/pull/3974 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 14 00:06:59 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 May 2021 10:06:59 +1000 Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v3] In-Reply-To: <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com> References: <1zxPj7o1LIT0ZFWPa8Ln8pj5jhni5_BLqNBsEOxM89Q=.c049eea1-db99-4a06-8968-6caa33a2e301@github.com> <9DWWaiSiiVwftGvwmLgOMMB_EMXByhnYed1Ykqs41kk=.91f30a36-9789-4b93-882c-d9876c9dca38@github.com> Message-ID: Thanks for the review Ioi! David On 14/05/2021 3:03 am, Ioi Lam wrote: > On Thu, 13 May 2021 04:59:11 GMT, David Holmes wrote: > >>> Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done t > hat pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: >>> >>> - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) >>> - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param >>> - Manifestations of Thread::current() become JavaThread::current() >>> - THREAD->as_Java_thread() becomes just THREAD >>> - THREAD->is_Java_thread() is reworked so that THREAD is "current" >>> >>> There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. >>> >>> Testing: >>> - tiers 1-8 on Linux-x64 >>> - all builds in tiers 1-4 >>> - tiers 1-3 on all platforms >>> >>> Thanks, >>> David >> >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Update after merge with master >> - Merge branch 'master' into 8252685-JavaThread >> - Review feedback from Serguei >> - Merge >> - 8252685: APIs that require JavaThread should take JavaThread arguments > > LGTM > > ------------- > > Marked as reviewed by iklam (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3877 > From ysuenaga at openjdk.java.net Fri May 14 00:53:37 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 14 May 2021 00:53:37 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> Message-ID: On Thu, 13 May 2021 18:28:24 GMT, Chris Plummer wrote: > I think maybe the property name of sun.jvm.hotspot.rmi.serverNamePrefix was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it sun.jvm.hotspot.rmi.serverName, and then appending an optional unique_id to it would make more sense. Agree. > What if instead of prefix you used servername and possibly also rename sun.jvm.hotspot.rmi.serverNamePrefix to sun.jvm.hotspot.rmi.serverName, but also keep legacy support in case someone is already using sun.jvm.hotspot.rmi.serverNamePrefix and decides to set it? Sounds good if we can do so! Indeed we need to send CSR for this issue, so we can do it. We do not need to think to pass parameters via system properties because we have SALauncher. So I think against this issue as following. Is it ok? * Add `--servername` option to debugd * debugd help describes about this as "instance name of debugd server" * man page of jhsdb describes that it is used for RMI object name, and describes "SARemoteDebugger" is set by default. * Connection string is `[unique_id@]host[:port][/servername]` * Change the description for `--serverid` in man page to "This is required if multiple debug servers are run on the same server instance. It would be added to RMI object name for server instance." * Will not change the help message because it seems to be enough to describe abstraction (A unique identifier for this debug server) * Declare that `sun.jvm.hotspot.rmi.serverNamePrefix` will be deprecated in the CSR, and show the warning if it is set ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From lzang at openjdk.java.net Fri May 14 02:10:55 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 02:10:55 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Thu, 13 May 2021 20:23:10 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Merge branch 'master' into s-fix >> - fix typo in comments >> - Merge branch 'master' into s-fix >> - Merge branch 'master' >> - Merge branch 'master' into sf >> - rename writeThrough to unbufferedMode and code refine >> - fix typo in comments >> - Merge branch 'master' into sf >> - Revert "reduce memory consumption" >> >> This reverts commit 70e43ddd453724ce36bf729fa6489c0027957b8e. >> - reduce memory consumption >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a02b1f29...6fde07bd > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528: > >> 1526: } >> 1527: writeInteger(0); >> 1528: writeInteger(size); > > You've added `writeInteger(size)` here, but I'm not sure where this used to be done. There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From lzang at openjdk.java.net Fri May 14 02:28:17 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 02:28:17 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11] In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com> > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out Lin Zang 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 14 additional commits since the last revision: - Merge branch 'master' into s-fix - Fix typo and add comment - Merge branch 'master' into s-fix - fix typo in comments - Merge branch 'master' into s-fix - Merge branch 'master' - Merge branch 'master' into sf - rename writeThrough to unbufferedMode and code refine - fix typo in comments - Merge branch 'master' into sf - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a0a8462d...01e1a107 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2803/files - new: https://git.openjdk.java.net/jdk/pull/2803/files/6fde07bd..01e1a107 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=09-10 Stats: 6272 lines in 202 files changed: 1865 ins; 3846 del; 561 mod Patch: https://git.openjdk.java.net/jdk/pull/2803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803 PR: https://git.openjdk.java.net/jdk/pull/2803 From lzang at openjdk.java.net Fri May 14 02:31:48 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 02:31:48 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11] In-Reply-To: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com> Message-ID: On Fri, 14 May 2021 02:28:17 GMT, Lin Zang wrote: >> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out > > Lin Zang 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 14 additional commits since the last revision: > > - Merge branch 'master' into s-fix > - Fix typo and add comment > - Merge branch 'master' into s-fix > - fix typo in comments > - Merge branch 'master' into s-fix > - Merge branch 'master' > - Merge branch 'master' into sf > - rename writeThrough to unbufferedMode and code refine > - fix typo in comments > - Merge branch 'master' into sf > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/2204d556...01e1a107 Thanks Chris for suggestion. I will conduct the tests today and update asap. ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From cjplummer at openjdk.java.net Fri May 14 03:56:46 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 03:56:46 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com> On Fri, 14 May 2021 02:08:13 GMT, Lin Zang wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1528: >> >>> 1526: } >>> 1527: writeInteger(0); >>> 1528: writeInteger(size); >> >> You've added `writeInteger(size)` here, but I'm not sure where this used to be done. > > There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks Ok, I missed that. I think where a comment is needed is with the first `writerInteger(0)`. It's not clear to me what that one is for. ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From cjplummer at openjdk.java.net Fri May 14 04:10:43 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 04:10:43 GMT Subject: RFR: 8263635: Add --prefix option to jhsdb debugd [v2] In-Reply-To: References: <2jm2CYpZR4y4AuLNUsXBBKWqAboQjshAyPYVE3YARUI=.5ab33ef8-bf82-4ebc-a333-7d04a7b6c22d@github.com> <1P5gNcTjqtonJA104Zncdw3gsaRatFN7H6mbF_LMN8c=.91280c5e-f677-449f-9eb9-108b3d9197da@github.com> Message-ID: On Fri, 14 May 2021 00:51:12 GMT, Yasumasa Suenaga wrote: >> I think this is better, but I think better help output is needed. `prefix` has a default and `unique_id` does not. I think both of these need to be mentioned in the help output. Also, if `unique_id` is not specified, then the value of `prefix` is the name of the RMI object, which seems a bit odd because it is suppose to be a prefix to a name, not the entire name. >> >> I think maybe the property name of `sun.jvm.hotspot.rmi.serverNamePrefix` was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it `sun.jvm.hotspot.rmi.serverName`, and then appending an optional `unique_id` to it would make more sense. >> >> What if instead of `prefix` you used `servername` and possibly also rename `sun.jvm.hotspot.rmi.serverNamePrefix` to `sun.jvm.hotspot.rmi.serverName`, but also keep legacy support in case someone is already using `sun.jvm.hotspot.rmi.serverNamePrefix` and decides to set it? > >> I think maybe the property name of sun.jvm.hotspot.rmi.serverNamePrefix was not a good choice, and is making it harder to come up with good argument names and syntax. If designing this from scratch, I would have called it sun.jvm.hotspot.rmi.serverName, and then appending an optional unique_id to it would make more sense. > > Agree. > >> What if instead of prefix you used servername and possibly also rename sun.jvm.hotspot.rmi.serverNamePrefix to sun.jvm.hotspot.rmi.serverName, but also keep legacy support in case someone is already using sun.jvm.hotspot.rmi.serverNamePrefix and decides to set it? > > Sounds good if we can do so! Indeed we need to send CSR for this issue, so we can do it. > We do not need to think to pass parameters via system properties because we have SALauncher. So I think against this issue as following. Is it ok? > > * Add `--servername` option to debugd > * debugd help describes about this as "instance name of debugd server" > * man page of jhsdb describes that it is used for RMI object name, and describes "SARemoteDebugger" is set by default. > * Connection string is `[unique_id@]host[:port][/servername]` > * Change the description for `--serverid` in man page to "This is required if multiple debug servers are run on the same server instance. It would be added to RMI object name for server instance." > * Will not change the help message because it seems to be enough to describe abstraction (A unique identifier for this debug server) > * Declare that `sun.jvm.hotspot.rmi.serverNamePrefix` will be deprecated in the CSR, and show the warning if it is set We already have a CSR. I think it can cover both the addition of `--servername` and the rename of `serverNamePrefix`. We need to be more consistent with the use of `serverid`. Between the man page, help output, and code we call use `serverid`, `` and `uniqueID`. We should use `serverid` in all cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From cjplummer at openjdk.java.net Fri May 14 04:48:35 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 04:48:35 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 23:34:29 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Drop exit_delta and the VMTestbase style of exiting on test failure. Overall it looks good. Some minor suggestions, most of which can be ignored if you wish. Is there a reason these tests were not placed under `test/jdk/java/lang/management`? test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70: > 68: // > 69: > 70: public class getLockOwnerName { Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: > 148: System.err.println("where:"); > 149: System.err.println(" -p ::= print debug info"); > 150: System.err.println(" time_max ::= max looping time in seconds"); `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324: > 322: > 323: // > 324: // Launch the blocker thread: The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads. test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: > 327: // - releases threadLock > 328: // > 329: if (getName().equals("blocker")) { Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From lzang at openjdk.java.net Fri May 14 07:09:45 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 07:09:45 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v10] In-Reply-To: <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> <8oyXWVSuwtRYsbfodxnK0uyl0mh2Xit0Ixg5JOM4XzE=.99e943e5-fde5-476f-8428-ba86dec0a53c@github.com> Message-ID: <8goAagr_Vyc741-zWx4_IiIQ-VCjsK7aaC5xP7JG2bg=.34640245-1158-44a4-b5f8-0af6a84b46b2@github.com> On Fri, 14 May 2021 03:53:27 GMT, Chris Plummer wrote: >> There used to be 2 writeInterger(0), and the second one is write the segment size with dummy value 0. I will add a comment here. Thanks > > Ok, I missed that. I think where a comment is needed is with the first `writerInteger(0)`. It's not clear to me what that one is for. OK, I will add it. it is a dummy value for `timestamp` slot.And seems it is never fill with real time stamp in current implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From rschmelter at openjdk.java.net Fri May 14 07:14:07 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Fri, 14 May 2021 07:14:07 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. Ralf Schmelter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Simplify thread_loop() - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 - Fix punctuation - Simplify code - Fix race in heap dump compression backend ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3628/files - new: https://git.openjdk.java.net/jdk/pull/3628/files/fb17cab8..1891197a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3628&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3628&range=00-01 Stats: 555249 lines in 4988 files changed: 44477 ins; 497699 del; 13073 mod Patch: https://git.openjdk.java.net/jdk/pull/3628.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3628/head:pull/3628 PR: https://git.openjdk.java.net/jdk/pull/3628 From rrich at openjdk.java.net Fri May 14 07:28:49 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 07:28:49 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > Ralf Schmelter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Simplify thread_loop() > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Fix punctuation > - Simplify code > - Fix race in heap dump compression backend LGTM ?? ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From lzang at openjdk.java.net Fri May 14 09:41:08 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 09:41:08 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v12] In-Reply-To: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out Lin Zang 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 16 additional commits since the last revision: - Merge branch 'master' into s-fix - add comment for the timestamp value - Merge branch 'master' into s-fix - Fix typo and add comment - Merge branch 'master' into s-fix - fix typo in comments - Merge branch 'master' into s-fix - Merge branch 'master' - Merge branch 'master' into sf - rename writeThrough to unbufferedMode and code refine - ... and 6 more: https://git.openjdk.java.net/jdk/compare/aac1e78c...c80a10e0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2803/files - new: https://git.openjdk.java.net/jdk/pull/2803/files/01e1a107..c80a10e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2803&range=10-11 Stats: 84 lines in 12 files changed: 16 ins; 39 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/2803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2803/head:pull/2803 PR: https://git.openjdk.java.net/jdk/pull/2803 From lzang at openjdk.java.net Fri May 14 09:41:18 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 14 May 2021 09:41:18 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v11] In-Reply-To: <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com> References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> <9waTwJ5eaX-nWBADd5H-yF3FPrpF_eA0pre3xnBFB24=.a25bddf7-5a2c-426f-877f-8faf312406f7@github.com> Message-ID: On Fri, 14 May 2021 02:28:17 GMT, Lin Zang wrote: >> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out > > Lin Zang 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 14 additional commits since the last revision: > > - Merge branch 'master' into s-fix > - Fix typo and add comment > - Merge branch 'master' into s-fix > - fix typo in comments > - Merge branch 'master' into s-fix > - Merge branch 'master' > - Merge branch 'master' into sf > - rename writeThrough to unbufferedMode and code refine > - fix typo in comments > - Merge branch 'master' into sf > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/45b46a08...01e1a107 Here are the tests I have conducted: 1. Passed test tier1 and tier2 (tier3 not executed) 2. Tested to dump netbeans with heap size at ~500MB, ~700MB and 1GB, and tested w/o `-gz` option from 1-9. all passed. 3. A workload that generate different object to fill heap, I have tested with heap usage from 1GB to 8GB with different `gz` options. All passed. Thanks ! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From rrich at openjdk.java.net Fri May 14 18:04:39 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 18:04:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Hi Robbin, there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good. Cheers, Richard. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47: > 45: JavaThread* current_java_thread = JavaThread::current(); > 46: assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm"); > 47: { Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: > 384: _waiters++; > 385: ret = simple_wait(self, millis); > 386: _waiters--; We don't own the monitor yet so you cannot modify `_waiters` here. Any reason you moved and duplicated this block? src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410: > 408: ret = simple_wait(self, millis); > 409: _waiters--; > 410: _recursions = save; The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again. src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > 50: // native for all operations. However we need to honor a suspend request, not > 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend > 52: // request// and reading the interrupt flag must be done from VM state `s/request///request/` ?? ------------- Changes requested by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From cjplummer at openjdk.java.net Fri May 14 18:07:47 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 18:07:47 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v12] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Fri, 14 May 2021 09:41:08 GMT, Lin Zang wrote: >> 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out > > Lin Zang 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 16 additional commits since the last revision: > > - Merge branch 'master' into s-fix > - add comment for the timestamp value > - Merge branch 'master' into s-fix > - Fix typo and add comment > - Merge branch 'master' into s-fix > - fix typo in comments > - Merge branch 'master' into s-fix > - Merge branch 'master' > - Merge branch 'master' into sf > - rename writeThrough to unbufferedMode and code refine > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/1672cc1a...c80a10e0 Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From cjplummer at openjdk.java.net Fri May 14 18:28:51 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 18:28:51 GMT Subject: RFR: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException [v2] In-Reply-To: References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Fri, 14 May 2021 07:14:07 GMT, Ralf Schmelter wrote: >> This fixes a race condition in the CompressionBackend class of the heap dump code. >> >> The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. >> >> The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. >> >> The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. > > Ralf Schmelter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Simplify thread_loop() > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8255661 > - Fix punctuation > - Simplify code > - Fix race in heap dump compression backend Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3628 From rrich at openjdk.java.net Fri May 14 19:45:11 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 14 May 2021 19:45:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan > > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 12/05/2021 8:56 pm, Robbin Ehn wrote: > > > On Wed, 12 May 2021 08:27:33 GMT, Richard Reingruber wrote: > > > Hi Robbin, > > > I haven't found the time for a proper review yet but I've experimented a little bit with lambdas. I could not make it work because g++ created references to ::new which isn't allowed. > > > Thanks, Richard. > > > > > > Hi Richard, > > I tested lamdba, which is just a fancy way to write a crazy typed functor, we need to capture the lamdba so we can run it in the destructor. AFAICT the way to do that is using std::function. > > Regarding ThreadClosure, we could use it, maybe that is preferable?! > > Isn't a ThreadClosure for applying an operation to a set of threads? > That is not what we are doing here. No it isn't. A closure is just a set of variable bindings and a function that can be executed. And yes we're doing just that. A ThreadClosure is just an instance of this general concept. E.g. an AsyncHandshakeClosure (subclass of ThreadClosure) is a function (plus variable bindings) that is passed by a requesting thread to a target thread to be executed by it. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dcubed at openjdk.java.net Fri May 14 22:14:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 22:14:56 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 04:45:36 GMT, Chris Plummer wrote: > Overall it looks good. Some minor suggestions, most of which can be ignored if you wish. Thanks for the review. I made some of the changes, but not all of them. > Is there a reason these tests were not placed under test/jdk/java/lang/management? These tests are for stressing particular HotSpot implementation pieces that are used by the M&M APIs. In particular, they are stressing the use of ThreadsListHandles in both the safepoint and non-safepoint code paths traveled by getThreadInfo(): // maxDepth == 0 requires no safepoint so alternate. int maxDepth = ((count % 1) == 1) ? Integer.MAX_VALUE : 0; info = mbean.getThreadInfo(id, maxDepth); if (info == null) { // the contender has exited break; } name = info.getLockOwnerName(); And we're stressing getLockOwnerName() because we had a non-reproducible bug that crashed in that particular function after the getThreadInfo() call. So I think this stress test (along with others that I've written in this family) belong in the test/hotspot collection of tests. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 70: > >> 68: // >> 69: >> 70: public class getLockOwnerName { > > Shouldn't this be called GetLockOwnerName? We don't usually use lower case for a class name. Looks like I did that because the API is called: ThreadInfo.getLockOwnerName() Will fix the filenames and the classname. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: > >> 148: System.err.println("where:"); >> 149: System.err.println(" -p ::= print debug info"); >> 150: System.err.println(" time_max ::= max looping time in seconds"); > > `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. It's a grammar notational style from my compiler theory days. I've used '::=' and ':=' for years. What would you like it changed to? Or can I just leave it and try to use '-' in the future? > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 324: > >> 322: >> 323: // >> 324: // Launch the blocker thread: > > The comment says "Launch the blocker thread", but this thread is already launched. Maybe drop "Launch" in favor of "Run", or just say "The block thread". Same comment for the other two threads. Fixed. > test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: > >> 327: // - releases threadLock >> 328: // >> 329: if (getName().equals("blocker")) { > > Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. This new test is a variation of a 20 year old test that I recently ported to JVM/TI and integrated. 20 years ago, it was much simpler to write the test this way. I could create a separate Thread subclass for each "role", but I'd rather not do that since it will no longer be easy to compare this test to its siblings. As for lambdas, I know absolutely zero about writing lambda code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 22:20:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 22:20:31 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v6] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: plummercj CR changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/771dafee..6a8e5e37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=04-05 Stats: 831 lines in 3 files changed: 415 ins; 415 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Fri May 14 22:44:54 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 22:44:54 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 21:54:46 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 150: >> >>> 148: System.err.println("where:"); >>> 149: System.err.println(" -p ::= print debug info"); >>> 150: System.err.println(" time_max ::= max looping time in seconds"); >> >> `::=` doesn't seem to be a convention we use in help output other than in the other recent tests you've added. > > It's a grammar notational style from my compiler theory days. > I've used '::=' and ':=' for years. What would you like it changed to? > Or can I just leave it and try to use '-' in the future? The convention for java tools seems to be to just use tabs to align the start of the argument descriptions: -p print debug info time_max max looping time in seconds ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From cjplummer at openjdk.java.net Fri May 14 22:57:39 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 14 May 2021 22:57:39 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 22:04:05 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/serviceability/monitoring/ThreadInfo/getLockOwnerName/getLockOwnerName.java line 329: >> >>> 327: // - releases threadLock >>> 328: // >>> 329: if (getName().equals("blocker")) { >> >> Bit of a nit here, but is there a reason not to just create separate Thread subclasses for each of the 3 types of threads you are handling here? Or just make these each separate static methods of the main class and use the instantiate the Thread class with a lambda. > > This new test is a variation of a 20 year old test that I recently ported to JVM/TI > and integrated. 20 years ago, it was much simpler to write the test this way. > I could create a separate Thread subclass for each "role", but I'd rather not > do that since it will no longer be easy to compare this test to its siblings. > > As for lambdas, I know absolutely zero about writing lambda code. Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them: // create thread with specified method as the "run" method Thread t = new Thread(this::testMethod); t.start(); // create thread with the specified code block as the "run" method Thread t1 = new Thread(() -> { synchronized (lock1) { System.out.println("Thread in sync section 1: " + Thread.currentThread().getName()); test1(); } // create a static Runnable object using a lambda and use it as the Runnable for a new Thread static final Runnable CONSUMER = () -> { remove(QUEUE); }; ... Thread t = new Thread(CONSUMER); ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:58:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:03 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Thu, 13 May 2021 18:01:27 GMT, Chris Plummer wrote: >> When reviewing this new test, is it worth comparing it with counter based tests that it was based on, or is it best just to view it as a completely new test. > >> @plummercj - Are you still planning to review this new test? > > Yes @plummercj - please mark this as 'Reviewed' if this latest version is acceptable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:58:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:03 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7] In-Reply-To: References: Message-ID: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: plummercj CR - drop '::=' from the usage() output. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3478/files - new: https://git.openjdk.java.net/jdk/pull/3478/files/6a8e5e37..185ee0f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3478&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3478/head:pull/3478 PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Fri May 14 23:58:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 14 May 2021 23:58:04 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 22:41:28 GMT, Chris Plummer wrote: >> It's a grammar notational style from my compiler theory days. >> I've used '::=' and ':=' for years. What would you like it changed to? >> Or can I just leave it and try to use '-' in the future? > > The convention for java tools seems to be to just use tabs to align the start of the argument descriptions: > > > -p print debug info > time_max max looping time in seconds Fixed. >> This new test is a variation of a 20 year old test that I recently ported to JVM/TI >> and integrated. 20 years ago, it was much simpler to write the test this way. >> I could create a separate Thread subclass for each "role", but I'd rather not >> do that since it will no longer be easy to compare this test to its siblings. >> >> As for lambdas, I know absolutely zero about writing lambda code. > > Ok. I get it about lambdas, but they can be useful for simplifying thread tasks without creating a subclass. Here are a few examples, but no need for you to replicate any them: > > > // create thread with specified method as the "run" method > Thread t = new Thread(this::testMethod); > t.start(); > > > > // create thread with the specified code block as the "run" method > Thread t1 = new Thread(() -> { > synchronized (lock1) { > System.out.println("Thread in sync section 1: " > + Thread.currentThread().getName()); > test1(); > } > > > > // create a static Runnable object using a lambda and use it as the Runnable for a new Thread > static final Runnable CONSUMER = () -> { > remove(QUEUE); > }; > ... > Thread t = new Thread(CONSUMER); I'll pass on the lambdas. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From ysuenaga at openjdk.java.net Sat May 15 02:00:15 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 15 May 2021 02:00:15 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3] In-Reply-To: References: Message-ID: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. > > serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. > And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: 8263635: Add --servername option to jhsdb debugd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3669/files - new: https://git.openjdk.java.net/jdk/pull/3669/files/af154a77..03ed5d19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=01-02 Stats: 131 lines in 12 files changed: 26 ins; 12 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/3669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669 PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Sat May 15 02:03:37 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 15 May 2021 02:03:37 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > 8263635: Add --servername option to jhsdb debugd @plummercj I updated the CSR and JBS issue to rename to `--servername`, and also I pushed new commit to follow them. It includes the update for help message, man page, and variable names. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From cjplummer at openjdk.java.net Sat May 15 03:00:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Sat, 15 May 2021 03:00:40 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v7] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 23:58:03 GMT, Daniel D. Daugherty wrote: >> The synopsis pretty much says it all. There's a more detailed history in the RFE itself. >> >> Currently running the new test thru Mach5 Tier[1-7]. >> I've run the test thru several 12 hour runs on my MBP13 and >> on my Linux-X64 server. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > plummercj CR - drop '::=' from the usage() output. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Sat May 15 13:17:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 15 May 2021 13:17:42 GMT Subject: RFR: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() [v5] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 08:12:22 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop exit_delta and the VMTestbase style of exiting on test failure. > > Hi Dan, > > Seems fine. Thanks for the updates. > > The proof of a test is in its execution :) > > David @dholmes-ora and @plummercj - Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From dcubed at openjdk.java.net Sat May 15 13:17:45 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 15 May 2021 13:17:45 GMT Subject: Integrated: 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:08:52 GMT, Daniel D. Daugherty wrote: > The synopsis pretty much says it all. There's a more detailed history in the RFE itself. > > Currently running the new test thru Mach5 Tier[1-7]. > I've run the test thru several 12 hour runs on my MBP13 and > on my Linux-X64 server. This pull request has now been integrated. Changeset: 8c71144a Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/8c71144a2392b8d2ce47074c819d56e523b50145 Stats: 503 lines in 2 files changed: 503 ins; 0 del; 0 mod 8265153: add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName() Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/3478 From lzang at openjdk.java.net Mon May 17 01:37:47 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Mon, 17 May 2021 01:37:47 GMT Subject: RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v8] In-Reply-To: References: <_4pksW9FB4VgM4sosjHs7q9lbPZtyGGy_wc_G53zLVg=.918f3888-1f52-4d30-bf1c-38e344af9e20@github.com> Message-ID: On Mon, 10 May 2021 23:19:37 GMT, Chris Plummer wrote: >> Hi Chris (@plummercj ) >> >> After several tries, I think maybe the current patch is the better way to fix this issue. >> For detail, there are three issues that cause the problem. >> - The incorrect calculated array length when segmented heap dump is enabled, it can be fixed easily by modifying code in method `calculateArrayMaxLength()`. It is already in this PR. >> - The internal segment buffer used for segmented heap dump. Plus the resize of this buffer can cause memory consumption by doing byte[] copy. >> - Also because the internal segment buffer is byte array, there is a limitation that the buffer length can not be larger than Integer.MAX_VALUE, which also cause the problem when dumping large array, as there can be integer overflow and also not align with the specification (as explained blow) >> >> Here are the possible solutions I have tried to avoid using `unbufferedMode`: >> >> - For segment heap dump, add limitation in `calculateArrayMaxLength()` to guarantee at most `Interger.MAX_VALUE` bytes can be filled into the internal byte array buffer. So there is no need to use unbufferedMode. But I found it can cause large memory usage with internal buffer resize to hold all array data, and also there is OOM thrown when I use `jhsdb jmap --binaryheap` command. Moreover it also changes the behavior of dumping large array: The original limitation is MAX_U4_VALUE, which follows the hprof spec that a segment in heap dump has a 32bit slot to hold the segment size. But after the change , it becomes to `Integer.MAX_VALUE`, which is 2^31-1, just the half of MAX_U4_VALUE, the behavior doesn't follow the spec exactly. >> The change also introduce lots of overflow check when size of internal segment buffer is used, which IMHO is not clean. >> >> - I also tried to avoid resize of internal segment buffer by using a linked list to hold all data to be flushed, this can avoid the overflow check. But it also cause OOM since the whole data are hold in the list. And it also introduce more codes for the linked list logic. >> >> And the main reason for caching data in internal segment buffer is that the current implentation needs to update the `size slot` in the segment header, which must be done before the whole data flushed to file, otherwise it would cause problems when gzip heap dump is used. >> >> The way to avoid caching is to calculate the object size previously and then update the size slot at begining. But it would cause other changes in the code, which IMO is not suitable to introduce in this PR. That is why I mentioned to re-write the implementation of `HeapHprofBinWriter.java` in previous comments. >> >> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. >> >> What do you think? >> >> Thanks, >> Lin > >> Having tried all these ways, I think maybe current solution with `unbufferedMode` is better. Because it is easy to calculate the array length in `calculateArrayMaxLength()` and hence know the size of the data to written. Then it can fill the `size` slot before data are seen, and avoid using the internal segment buffer by write large array data directly to file. > > I think that makes sense. Is this now fully implemented in this PR and it is ready for a final review? Thanks @plummercj for review and approve this PR. Dear All, May I get more review? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/2803 From dholmes at openjdk.java.net Mon May 17 01:38:47 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 01:38:47 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 17:53:15 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: > >> 384: _waiters++; >> 385: ret = simple_wait(self, millis); >> 386: _waiters--; > > We don't own the monitor yet so you cannot modify `_waiters` here. > Any reason you moved and duplicated this block? Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait. This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Mon May 17 04:07:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 04:07:44 GMT Subject: RFR: 8252685: APIs that require JavaThread should take JavaThread arguments [v4] In-Reply-To: References: Message-ID: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into 8252685-JavaThread - Update after merge with master - Merge branch 'master' into 8252685-JavaThread - Review feedback from Serguei - Merge - 8252685: APIs that require JavaThread should take JavaThread arguments ------------- Changes: https://git.openjdk.java.net/jdk/pull/3877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3877&range=03 Stats: 535 lines in 120 files changed: 14 ins; 28 del; 493 mod Patch: https://git.openjdk.java.net/jdk/pull/3877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3877/head:pull/3877 PR: https://git.openjdk.java.net/jdk/pull/3877 From dholmes at openjdk.java.net Mon May 17 04:08:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 17 May 2021 04:08:28 GMT Subject: Integrated: 8252685: APIs that require JavaThread should take JavaThread arguments In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote: > Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it must be a JavaThread, rather than taking/manifesting a JavaThread in the first place. The main reason for this is that the TRAPS macro, used in relation to exception generation and processing, is declared as "Thread* THREAD". In practice only JavaThreads that can execute Java code can generate arbitrary exceptions, because it requires executing Java code. In other places we can get away with other kinds of threads "throwing" exceptions because they are only pre-allocated instances that require no Java code execution (e.g. OOME), or when executed by a non-JavaThread the code actually by-passes the logic would throw an exception. Such code also eventually clears the exception and reports the OOM by some other means. We have been progressively untangling these code paths and modifying TRAPS/CHECK usage so that only JavaThreads will call TRAPS methods and throw exceptions. Having done th at pre-work we are now ready to convert TRAPS to be "JavaThread* THREAD" and that is what this change does. The resulting changes are largely mechanical: > > - declarations of "Thread* THREAD" become "JavaThread* THREAD" (where THREAD is needed for exceptions, otherwise THREAD is renamed to current) > - methods that took a Thread* parameter that was always THREAD, now take a JavaThread* param > - Manifestations of Thread::current() become JavaThread::current() > - THREAD->as_Java_thread() becomes just THREAD > - THREAD->is_Java_thread() is reworked so that THREAD is "current" > > There are still places where a CompilerThread (which is a JavaThread but may not be able to execute Java code) calls a TRAPS function (primarily where OOME is possible). Fixing that would be a future RFE and may not be possible without reworking a lot of the allocation code paths. > > Testing: > - tiers 1-8 on Linux-x64 > - all builds in tiers 1-4 > - tiers 1-3 on all platforms > > Thanks, > David This pull request has now been integrated. Changeset: 02f895c5 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/02f895c5f6f6de38549337d45ed8ba4c446e9677 Stats: 535 lines in 120 files changed: 14 ins; 28 del; 493 mod 8252685: APIs that require JavaThread should take JavaThread arguments Reviewed-by: coleenp, sspitsyn, kvn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3877 From rehn at openjdk.java.net Mon May 17 07:05:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:05:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> On Thu, 13 May 2021 05:22:51 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: > >> 46: // The rules are: >> 47: // - We must never safepoint poll if raw monitor is owned. >> 48: // - We may safepoint poll before it is owned and after it has been released. > > I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: JavaThread: -lock RM LOOP { -wait RM -do stufff with data from VM thread } -unlock RM The user do not call into the VM/Java. VM Thread: -safepoint -lock RM -notify RM -unlock RM If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. But he would also deadlock if he used a pthread mutex because that code would be buggy. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Mon May 17 07:23:26 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 May 2021 17:23:26 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> References: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> Message-ID: <87e79d33-1c7f-3d0f-edfb-3376d3c267d9@oracle.com> On 17/05/2021 5:05 pm, Robbin Ehn wrote: > On Thu, 13 May 2021 05:22:51 GMT, David Holmes wrote: > >>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fixes for Dan >> >> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: >> >>> 46: // The rules are: >>> 47: // - We must never safepoint poll if raw monitor is owned. >>> 48: // - We may safepoint poll before it is owned and after it has been released. >> >> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. > > This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: > JavaThread: > -lock RM > LOOP { > -wait RM > -do stufff with data from VM thread > } > -unlock RM > > The user do not call into the VM/Java. > > VM Thread: > -safepoint > -lock RM > -notify RM > -unlock RM > > If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. > > If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. Only if the VMThread executes code that uses the same RM - which should be a rare occurrence. David ----- > But he would also deadlock if he used a pthread mutex because that code would be buggy. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From rehn at openjdk.java.net Mon May 17 07:24:40 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:24:40 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 05:24:03 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 96: > >> 94: protected: >> 95: JvmtiRawMonitor* _rm; >> 96: bool _rm_exit; > > If this signifies the monitor exited then please name it `_rm_exited`. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 07:45:39 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:45:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 05:46:59 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: > >> 275: class ThreadBlockInVM { >> 276: InFlightMutexRelease _ifmr; >> 277: ThreadBlockInVMPreprocess _tbivmpp; > > Why delegate to the TBIVMPP instead of extending it? I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 07:58:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:58:23 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 09:50:56 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 47: > >> 45: JavaThread* current_java_thread = JavaThread::current(); >> 46: assert(current_java_thread->thread_state() == _thread_in_vm, "Must be in vm"); >> 47: { > > Looks like the assertion in L46 is redundant now. ThreadToNativeFromVM asserts as well. Fixed > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 410: > >> 408: ret = simple_wait(self, millis); >> 409: _waiters--; >> 410: _recursions = save; > > The values of `_waiters` and `_recursions` should be adjusted after the monitor is owned again. Fixed > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 52: > >> 50: // native for all operations. However we need to honor a suspend request, not >> 51: // entering a monitor if suspended, and check for interrupts. Honoring a suspend >> 52: // request// and reading the interrupt flag must be done from VM state > > `s/request///request/` ?? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 07:58:24 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 07:58:24 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <165oJPFEipZ7u6iG0buImc-eTxwyPf-EOkKn3GpzlJg=.13f86155-ddf6-4ccb-aee9-9df674081520@github.com> On Mon, 17 May 2021 01:36:05 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 386: >> >>> 384: _waiters++; >>> 385: ret = simple_wait(self, millis); >>> 386: _waiters--; >> >> We don't own the monitor yet so you cannot modify `_waiters` here. >> Any reason you moved and duplicated this block? > > Good catch! Even if the block wasn't moved we still no longer own the monitor after simple_wait. > > This is going to be tricky to fix in a clear/clean way as the waiters count has to be maintained properly. Actually the field is unused. The _entry_list is the list of waiters, which is the only thing we really care about. If there was a reader of _waiter reading it without lock can only be used as some kind of hint. If you have lock you can just check _entry_list. I duplicated it because otherwise I would need two branchse on if (self->is_Java_thread()) which creates more complicated code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 17 08:09:09 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 08:09:09 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <3j6Egl0cd7pkHjWQfOTr65Kpk_7OmNLfo8xYK_AfWjM=.a97f7d87-06b6-46bc-b30d-75f12391f96f@github.com> On Thu, 13 May 2021 05:57:55 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/objectMonitor.cpp line 435: > >> 433: EnterI(current); >> 434: } >> 435: if (!eos.om_op_done()) { > > I find this API too generic. I'd much rather see: > > if (!eos.exited()) { > assert ... > break; > } Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _om_op_done; > > Please rename to _exited - we know what the "op" is so no need to use generic terminology. Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 313: > >> 311: ExitOnSuspend(ObjectMonitor* om) : _om(om), _om_op_done(false) {} >> 312: void operator()(JavaThread* current); >> 313: bool om_op_done() { return _om_op_done; } > > please rename to exited() Fixed > src/hotspot/share/runtime/objectMonitor.hpp line 315: > >> 313: bool om_op_done() { return _om_op_done; } >> 314: }; >> 315: class ClearSuccOnSuspend : public ExitOnSuspend { > > I don't see why there is any relationship between these two. You don't clear-succ and exit. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From github.com+2217224+kariya-mitsuru at openjdk.java.net Mon May 17 08:10:45 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya) Date: Mon, 17 May 2021 08:10:45 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v4] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 06:35:43 GMT, Mitsuru Kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Hi, Would anyone sponsor it? Best regards, Mitsuru ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From rehn at openjdk.java.net Mon May 17 08:29:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 08:29:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <5z8gIP9ALINo5U1RdyqJiZQFb1BlYA69zR-8PUQsa0Q=.76c28c76-7eda-4acd-b744-cb39c018bec0@github.com> On Thu, 13 May 2021 05:27:42 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 207: > >> 205: assert(_thread->thread_state() == _thread_in_vm, "coming from wrong thread state"); >> 206: assert(!_thread->has_last_Java_frame() || _thread->frame_anchor()->walkable(), "Unwalkable stack in vm->native transition"); >> 207: _thread->set_thread_state(_thread_in_native); > > After doing a heavyweight transition for many many years I find it somewhat disconcerting to suddenly be told it is not necessary. If we are _thread_in_vm and so unsafe, then no handshake/safepoint can have been processed, so there is nothing to check. Makes sense. But how long has that been true? Could we have simplified this years ago or it is a result of other changes? I looked over the transitions this fall, I don't know but there are some of these oddities. One problem is the some of the generic named transitions RAII are actually supposed to be used only at certain places and some optimizations have been added. E.g. in this case someone have figured out that we can remove make_walkable(), but as a generic rule when going to a safe state (blocked/native) you should call make_walkable. My guess is that calling make_walkable on every JNI/JVM TI call was expensive on Solaris, so someone optimized that. Now I'm unsure if that is actually true (I my feeling is no, because we could accidentally call Java if we hit e.g. class loading or something). And the optimization is no longer valid, make_walkable() is light weight on current hardware AFAIK. I updated to what I see as a correct transition to an safe state without any short cuts. I also notice I missed an assert from the previous code. Re-running all test, since these kinds of changes should not be taken lightly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rrich at openjdk.java.net Mon May 17 09:35:46 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 17 May 2021 09:35:46 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395: > 393: ThreadBlockInVMPreprocess tbivmp(jt, eos); > 394: simple_enter(jt); > 395: _recursions = save; I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From github.com+2217224+kariya-mitsuru at openjdk.java.net Mon May 17 09:54:10 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya) Date: Mon, 17 May 2021 09:54:10 GMT Subject: Integrated: 8264734: Some SA classes could use better hashCode() implementation In-Reply-To: References: Message-ID: <6wpLFPjMzqSlUYxZ4g-OImbXZXNVLm0J8yj-e7mYiXI=.af64f451-598d-4690-824a-12e4f6715003@github.com> On Thu, 15 Apr 2021 15:44:15 GMT, Mitsuru Kariya wrote: > The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. > This PR changes to use `Long.hashCode` instead. This pull request has now been integrated. Changeset: a555fd89 Author: Mitsuru Kariya Committer: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/a555fd89d040792d4de73ab67d86b171a38cfde6 Stats: 26 lines in 11 files changed: 0 ins; 6 del; 20 mod 8264734: Some SA classes could use better hashCode() implementation Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From rehn at openjdk.java.net Mon May 17 11:24:42 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 17 May 2021 11:24:42 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 09:32:23 GMT, Richard Reingruber wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 395: > >> 393: ThreadBlockInVMPreprocess tbivmp(jt, eos); >> 394: simple_enter(jt); >> 395: _recursions = save; > > I think you should restore `_recursions` only when finally leaving the loop because if you do it here and exit the monitor again because of a suspend then another thread could hit the `guarantee(_recursions == 0, "invariant")` at L349. This is a preexisting issue but since you're modifying this I reckon it makes sense to correct it. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rschmelter at openjdk.java.net Mon May 17 11:50:43 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Mon, 17 May 2021 11:50:43 GMT Subject: Integrated: JDK-8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException In-Reply-To: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> References: <86dHIIPWbz8odspCOyq_V0APxg377Xf_UhMKslSFUOk=.7dd3cda0-3294-4f7c-84b6-65180cfc7042@github.com> Message-ID: On Thu, 22 Apr 2021 14:16:21 GMT, Ralf Schmelter wrote: > This fixes a race condition in the CompressionBackend class of the heap dump code. > > The race happens when the thread iterating the heap wants to write the data it has collected. If the compression backend has worker threads, the buffer to write would just be added to a queue and the worker threads would then compress (if needed) and write the buffer. But if no worker threads are present, the thread doing the iteration must do this itself. > > The iterating thread checks the _nr_of_threads member under lock protection and if it is 0, it assume it would have to do the work itself. It then releases the lock and enters the loop of the worker threads for one round. But after the lock has been released, a worker thread could be registered and handle the buffer itself. Then the iterating thread would wait until another buffer is available, which will never happen. > > The fix is to take the buffer to write out of the queue in the iterating thread under lock protection and the do the unlocking. This pull request has now been integrated. Changeset: a29612ea Author: Ralf Schmelter URL: https://git.openjdk.java.net/jdk/commit/a29612ea9998a8e45f25add7ae30bfbc62ce3756 Stats: 51 lines in 3 files changed: 15 ins; 24 del; 12 mod 8255661: TestHeapDumpOnOutOfMemoryError fails with EOFException Reviewed-by: rrich, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/3628 From ysuenaga at openjdk.java.net Mon May 17 12:15:01 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 17 May 2021 12:15:01 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 Message-ID: Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). * serviceability/sa/ClhsdbDumpheap.java * serviceability/sa/ClhsdbFindPC.java * serviceability/sa/ClhsdbInspect.java * serviceability/sa/ClhsdbSymbol.java * serviceability/sa/TestHeapDumpForInvokeDynamic.java * serviceability/sa/TestJmapCore.java * serviceability/sa/TestJmapCoreMetaspace.java They need to handle relocated objects and/or live regions (pages). SA should handle them. This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help? ------------- Commit messages: - Improve relocation handling - Merge remote-tracking branch 'upstream/master' into JDK-8266957 - 8266957: SA has not followed JDK-8220587 and JDK-8224965 Changes: https://git.openjdk.java.net/jdk/pull/4057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4057&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266957 Stats: 799 lines in 23 files changed: 558 ins; 191 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/4057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4057/head:pull/4057 PR: https://git.openjdk.java.net/jdk/pull/4057 From github.com+2217224+kariya-mitsuru at openjdk.java.net Mon May 17 12:40:47 2021 From: github.com+2217224+kariya-mitsuru at openjdk.java.net (Mitsuru Kariya) Date: Mon, 17 May 2021 12:40:47 GMT Subject: RFR: 8264734: Some SA classes could use better hashCode() implementation [v4] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 06:35:43 GMT, Mitsuru Kariya wrote: >> The current `hashCode` implementation of SA's Address subclasses ignores the upper 32 bits of the long value. >> This PR changes to use `Long.hashCode` instead. > > Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thanks a lot! ------------- PR: https://git.openjdk.java.net/jdk/pull/3522 From weijun at openjdk.java.net Mon May 17 22:01:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:49 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) ``` The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. ------------- Commit messages: - test for awt - test for hotspot-gc - test for compiler - test for net - test for core-libs - test for beans - test for xml - test for nio - test for hotspot-runtime - test for security - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0 Changes: https://git.openjdk.java.net/jdk/pull/4071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267184 Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Mon May 17 22:01:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:52 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). The code change is divided into 3 commits. Please review them one by one. 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. ------------- Commit messages: - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266459 Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 17 22:01:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration. Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 + @SuppressWarnings("removal") There are also 7 cases where an existing annotation is updated ================= 2 ==================== - @SuppressWarnings("deprecation") + @SuppressWarnings({"removal","deprecation"}) ================= 1 ==================== - @SuppressWarnings("Convert2Lambda") + @SuppressWarnings({"removal","Convert2Lambda"}) ================= 1 ==================== - @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"}) + @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"}) ================= 1 ==================== - @SuppressWarnings("deprecation") // Use of RMISecurityManager + @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager ================= 1 ==================== - @SuppressWarnings("unchecked") /*To suppress warning from line 1374*/ + @SuppressWarnings({"removal","unchecked"}) /*To suppress warning from line 1374*/ ================= 1 ==================== - @SuppressWarnings("fallthrough") + @SuppressWarnings({"removal","fallthrough"}) All other cases are new annotation embedded inline: ================= 7 ==================== - AccessControlContext acc) { + @SuppressWarnings("removal") AccessControlContext acc) { ================= 4 ==================== - AccessControlContext acc, + @SuppressWarnings("removal") AccessControlContext acc, ================= 3 ==================== - AccessControlContext context, + @SuppressWarnings("removal") AccessControlContext context, ================= 3 ==================== - AccessControlContext acc) + @SuppressWarnings("removal") AccessControlContext acc) ================= 2 ==================== - try (InputStream stream = AccessController.doPrivileged(pa)) { + try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) { ================= 2 ==================== - AccessControlContext context, Permission... perms) { + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { ================= 2 ==================== - } catch (java.security.AccessControlException e) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException e) { ================= 2 ==================== - } catch (AccessControlException ace) { + } catch (@SuppressWarnings("removal") AccessControlException ace) { ================= 2 ==================== - AccessControlContext context) + @SuppressWarnings("removal") AccessControlContext context) ================= 2 ==================== - AccessControlContext acc) throws LoginException { + @SuppressWarnings("removal") AccessControlContext acc) throws LoginException { ================= 2 ==================== - } catch (AccessControlException e) { + } catch (@SuppressWarnings("removal") AccessControlException e) { ================= 1 ==================== - public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) { + public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - DomainCombiner combiner, + @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - } catch (java.security.AccessControlException ace) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) { ================= 1 ==================== - private static File checkFile(File f, SecurityManager sm) { + private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static File checkFile(File file, SecurityManager sm) { + private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm, + private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm, ================= 1 ==================== - ProtectionDomain[] getProtectDomains(AccessControlContext context); + ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - SecureCallbackHandler(java.security.AccessControlContext acc, + SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc, ================= 1 ==================== - private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) { + private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - private void checkMemberAccess(SecurityManager sm, int which, + private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which, ================= 1 ==================== - private static File[] checkFiles(Stream filesStream, SecurityManager sm) { + private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - Thread(Runnable target, AccessControlContext acc) { + Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public ProtectionDomain[] getProtectDomains(AccessControlContext context) { + public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext stack, - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext stack, + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext(ProtectionDomain caller, DomainCombiner combiner, + AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - public URLClassPath(URL[] urls, AccessControlContext acc) { + public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - URLClassLoader(URL[] urls, AccessControlContext acc) { + URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public static void setSecurityManager(SecurityManager sm) { + public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - try (DataInputStream dis = new DataInputStream(new InflaterInputStream( + try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream( ================= 1 ==================== - try (FileInputStream fis = AccessController.doPrivileged( + try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged( ================= 1 ==================== - FactoryURLClassLoader(URL[] urls, AccessControlContext acc) { + FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - Thread newThreadWithAcc(Runnable target, AccessControlContext acc); + Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc); ================= 1 ==================== - SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) { + SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) { ================= 1 ==================== - private PolicyDelegate(PolicySpi spi, Provider p, + private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p, ================= 1 ==================== - DomainCombiner combiner) { + @SuppressWarnings("removal") DomainCombiner combiner) { ================= 1 ==================== - PrivilegedRunnable(Runnable r, AccessControlContext acc) { + PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private static File[] checkFiles(Stream fs, SecurityManager sm) { + private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private void checkSpecifyHandler(SecurityManager sm) { + private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - String serverPrincipal, AccessControlContext acc) + String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc) ================= 1 ==================== - public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) { + public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() { + try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() { ================= 1 ==================== - public EventFileStream(AccessControlContext acc, Path path) throws IOException { + public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException { ================= 1 ==================== - AccessControlContext context, Permission... perms) + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) ================= 1 ==================== - private static void privateCheckPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { ================= 1 ==================== - AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { + AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { ================= 1 ==================== - private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl, + private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl, ================= 1 ==================== - AccessControlContext context) { + @SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - public PrivilegedExecutor(Executor executor, AccessControlContext acc) { + public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) { + private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) { ================= 1 ==================== - try (BufferedReader bufferedReader = + try (@SuppressWarnings("removal") BufferedReader bufferedReader = ================= 1 ==================== - private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { **That's all**. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From cjplummer at openjdk.java.net Mon May 17 22:15:22 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 17 May 2021 22:15:22 GMT Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR Message-ID: The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail. The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best: https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953 There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change. ------------- Commit messages: - Use p_memsz instead of p_filesz to correctly compute segment size. Changes: https://git.openjdk.java.net/jdk/pull/4075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4075&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263242 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4075/head:pull/4075 PR: https://git.openjdk.java.net/jdk/pull/4075 From erikj at openjdk.java.net Mon May 17 22:30:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 22:30:56 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Makefile change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From dholmes at openjdk.java.net Tue May 18 05:01:46 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 18 May 2021 05:01:46 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Changes to hotspot-* and serviceability look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 05:51:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 05:51:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Marked as reviewed by alanb (Reviewer). The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. For uses using ProcessTools then it seems to be very random. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 06:33:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 06:33:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. src/java.base/share/classes/java/lang/SecurityManager.java line 315: > 313: * > 314: * @since 1.0 > 315: * @deprecated The Security Manager is deprecated and subject to removal in a Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From kevinw at openjdk.java.net Tue May 18 08:52:42 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 18 May 2021 08:52:42 GMT Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR In-Reply-To: References: Message-ID: On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer wrote: > The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail. > > The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best: > > https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953 > > There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4075 From ysuenaga at openjdk.java.net Tue May 18 09:00:41 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 18 May 2021 09:00:41 GMT Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR In-Reply-To: References: Message-ID: On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer wrote: > The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail. > > The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best: > > https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953 > > There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change. Marked as reviewed by ysuenaga (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4075 From dfuchs at openjdk.java.net Tue May 18 11:33:44 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 18 May 2021 11:33:44 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too. test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > 32: * @run clean NotificationEmissionTest > 33: * @run build NotificationEmissionTest > 34: * @run main NotificationEmissionTest 1 This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From mullan at openjdk.java.net Tue May 18 12:44:48 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 12:44:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/lang/SecurityManager.java line 315: > >> 313: * >> 314: * @since 1.0 >> 315: * @deprecated The Security Manager is deprecated and subject to removal in a > > Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? It includes both: ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 14:01:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:01:41 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34: > >> 32: * @run clean NotificationEmissionTest >> 33: * @run build NotificationEmissionTest >> 34: * @run main NotificationEmissionTest 1 > > This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well? Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Tue May 18 14:07:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 14:07:38 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman wrote: > The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g. > > test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after. > > test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters. > > For uses using ProcessTools then it seems to be very random. I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From alanb at openjdk.java.net Tue May 18 15:22:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 15:22:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to removal in a >> >> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? > > It includes both: > ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mullan at openjdk.java.net Tue May 18 15:49:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 15:49:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com> On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote: >> It includes both: >> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) > > Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From darcy at openjdk.java.net Tue May 18 16:29:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 18 May 2021 16:29:47 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From chegar at openjdk.java.net Tue May 18 16:38:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 18 May 2021 16:38:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The changes in the net area look fine. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From naoto at openjdk.java.net Tue May 18 16:45:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 16:45:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Reviewed i18n/java.time/charset. They all look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Tue May 18 17:30:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 18 May 2021 17:30:39 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. java.xml changes look good. Thanks. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue May 18 17:39:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 17:39:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/security/AccessController.java line 877: > 875: @CallerSensitive > 876: public static T doPrivileged(PrivilegedExceptionAction action, > 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Tue May 18 17:43:39 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:43:39 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. I reviewed non-client areas. Looks okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From mchung at openjdk.java.net Tue May 18 17:53:51 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:53:51 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 18:42:26 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 18:42:26 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/security/AccessController.java line 877: > >> 875: @CallerSensitive >> 876: public static T doPrivileged(PrivilegedExceptionAction action, >> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) > > you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 21:13:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:13:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/AccessController.java line 877: >> >>> 875: @CallerSensitive >>> 876: public static T doPrivileged(PrivilegedExceptionAction action, >>> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) >> >> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. > > I'll try to update my auto-annotating program. Turns out this only happens in this class: $ rg '^\s*@SuppressWarnings("removal").*?,.' src/java.base/share/classes/java/security/AccessController.java:449: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:514: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) I'll fix them manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From cjplummer at openjdk.java.net Tue May 18 21:21:38 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 18 May 2021 21:21:38 GMT Subject: RFR: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR In-Reply-To: References: Message-ID: On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer wrote: > The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail. > > The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best: > > https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953 > > There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4075 From weijun at openjdk.java.net Tue May 18 21:21:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:21:45 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: feedback from Sean, Phil and Alan ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01 Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From cjplummer at openjdk.java.net Tue May 18 21:29:41 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 18 May 2021 21:29:41 GMT Subject: Integrated: 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR In-Reply-To: References: Message-ID: On Mon, 17 May 2021 22:05:19 GMT, Chris Plummer wrote: > The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail. > > The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best: > > https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953 > > There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change. This pull request has now been integrated. Changeset: 10236e7a Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/10236e7a52a2dd117c3639d020cfe294797f57af Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod 8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR Reviewed-by: kevinw, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/4075 From weijun at openjdk.java.net Tue May 18 21:44:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:44:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: adjust order of VM options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01 Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From rehn at openjdk.java.net Wed May 19 07:26:14 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:14 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: Message-ID: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/1c6448e3..a8b8469c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=02-03 Stats: 23290 lines in 735 files changed: 8980 ins; 9379 del; 4931 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:17 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:17 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 08:04:47 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Updated, passed t1-t7 och local stress-testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:19 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:19 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Thu, 13 May 2021 06:04:19 GMT, David Holmes wrote: > Hi Robbin, > > Sorry for the delay in getting through this. > > Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. > > Thanks, > David Thanks for looking at, update after comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Wed May 19 07:26:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 19 May 2021 07:26:20 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 18:02:12 GMT, Richard Reingruber wrote: > Hi Robbin, > > there seem to be issues in the jvmtiRawMonitor part of the change. Besides that it looks good. > > Cheers, Richard. Thanks and thanks for finding the two issues, updated! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From lzang at openjdk.java.net Wed May 19 11:55:12 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 19 May 2021 11:55:12 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25] In-Reply-To: References: Message-ID: > 8252842: Extend jmap to support parallel heap dump Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - fix build issue after rebase and fix one issue - Merge branch 'master' - Merge branch 'master' into pd - update copyright info - Merge branch 'master' into par-dump - undo JMap.java - code refine and typo fix - Merge branch 'master' into par-dump - refine with several fix - Merge branch 'master' into par-dump - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b ------------- Changes: https://git.openjdk.java.net/jdk/pull/2261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=24 Stats: 835 lines in 5 files changed: 648 ins; 57 del; 130 mod Patch: https://git.openjdk.java.net/jdk/pull/2261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261 PR: https://git.openjdk.java.net/jdk/pull/2261 From lzang at openjdk.java.net Wed May 19 12:02:00 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Wed, 19 May 2021 12:02:00 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v22] In-Reply-To: References: Message-ID: <9yxlJK34rPBqiP47CNcvVmr_zdd3wMNUZblx2EQWVA4=.437cb8bf-7dd8-47e0-9351-51478fd8c0bd@github.com> On Mon, 10 May 2021 23:29:36 GMT, Chris Plummer wrote: >> Lin Zang has updated the pull request incrementally with one additional commit since the last revision: >> >> code refine and typo fix > > I think you still need to undo the JMap.java changes since they are now being handled by #3598 Hi Chris (@plummercj), May I ask your help to remove the `csr` label? As we discussed before, there is no need for this PR to have CSR. Thanks! Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From weijun at openjdk.java.net Wed May 19 13:47:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:54 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com> On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > feedback from Sean, Phil and Alan A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 13:47:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From rrich at openjdk.java.net Wed May 19 14:28:48 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 19 May 2021 14:28:48 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Just one more, rather unimportant comment... Either way: LGTM! Thanks, Richard. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > 380: > 381: _recursions = 0; > 382: ret = simple_wait(self, millis); IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. _recursions = 0; ret = simple_wait(self, millis); _recursions = save; ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From ayang at openjdk.java.net Wed May 19 17:05:49 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 19 May 2021 17:05:49 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3756 From ayang at openjdk.java.net Wed May 19 17:05:50 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 19 May 2021 17:05:50 GMT Subject: Integrated: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:23:31 GMT, Albert Mingkun Yang wrote: > It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. This pull request has now been integrated. Changeset: 99fcc410 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/99fcc410a774e7b830856aa9c8e18e8a3b0567de Stats: 43 lines in 5 files changed: 0 ins; 36 del; 7 mod 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set Reviewed-by: tschatzl, sjohanss, pliden, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3756 From prr at openjdk.java.net Wed May 19 18:16:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:16:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > 57: ProcessCommunicator > 58: .executeChildProcess(Consumer.class, new String[0]); > 59: if (!"Hello".equals(processResults.getStdOut())) { Who or what prompted this change ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:19:49 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:19:49 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This change is so large that github won't even display the list of files so I can't jump to where I want to go ! And when I try to scroll I get just a blank page. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:29:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:29:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java src/java.desktop/share/classes/java/awt/Component.java line 217: > 215: * @author Sami Shaio > 216: */ > 217: @SuppressWarnings("removal") Why is this placed on the *entire class* ?? This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. src/java.desktop/share/classes/java/awt/Container.java line 97: > 95: * @since 1.0 > 96: */ > 97: @SuppressWarnings("removal") Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. Where else are you adding this to entire classes instead of the specific site ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:41:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:41:44 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:26:25 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.desktop/share/classes/java/awt/Component.java line 217: > >> 215: * @author Sami Shaio >> 216: */ >> 217: @SuppressWarnings("removal") > > Why is this placed on the *entire class* ?? > This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is s = java.security.AccessController.doPrivileged( new GetPropertyAction("awt.image.redrawrate")); > src/java.desktop/share/classes/java/awt/Container.java line 97: > >> 95: * @since 1.0 >> 96: */ >> 97: @SuppressWarnings("removal") > > Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. > > Where else are you adding this to entire classes instead of the specific site ? Similar as the one above, it's because of static { // Don't lazy-read because every app uses invalidate() isJavaAwtSmartInvalidate = AccessController.doPrivileged( new GetBooleanAction("java.awt.smartInvalidate")); } > test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > >> 57: ProcessCommunicator >> 58: .executeChildProcess(Consumer.class, new String[0]); >> 59: if (!"Hello".equals(processResults.getStdOut())) { > > Who or what prompted this change ? The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:46:46 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:46:46 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Container.java line 97: >> >>> 95: * @since 1.0 >>> 96: */ >>> 97: @SuppressWarnings("removal") >> >> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. >> >> Where else are you adding this to entire classes instead of the specific site ? > > Similar as the one above, it's because of > > static { > // Don't lazy-read because every app uses invalidate() > isJavaAwtSmartInvalidate = AccessController.doPrivileged( > new GetBooleanAction("java.awt.smartInvalidate")); > } We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:51:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:51:43 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote: >> Similar as the one above, it's because of >> >> static { >> // Don't lazy-read because every app uses invalidate() >> isJavaAwtSmartInvalidate = AccessController.doPrivileged( >> new GetBooleanAction("java.awt.smartInvalidate")); >> } > > We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 19:34:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 19:34:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Component.java line 217: >> >>> 215: * @author Sami Shaio >>> 216: */ >>> 217: @SuppressWarnings("removal") >> >> Why is this placed on the *entire class* ?? >> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. > > This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is > > s = java.security.AccessController.doPrivileged( > new GetPropertyAction("awt.image.redrawrate")); That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. You can define a static private method to contain this and call it from the static initializer block. Much better than applying the annotation to an entire class. --- a/src/java.desktop/share/classes/java/awt/Component.java +++ b/src/java.desktop/share/classes/java/awt/Component.java @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, */ static boolean isInc; static int incRate; + + private static void initIncRate() { + String s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.incrementaldraw")); + isInc = (s == null || s.equals("true")); + + s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.redrawrate")); + incRate = (s != null) ? Integer.parseInt(s) : 100; + } + static { /* ensure that the necessary native libraries are loaded */ Toolkit.loadLibraries(); @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, if (!GraphicsEnvironment.isHeadless()) { initIDs(); } - - String s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.incrementaldraw")); - isInc = (s == null || s.equals("true")); - - s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.redrawrate")); - incRate = (s != null) ? Integer.parseInt(s) : 100; + initIncRate(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From snazarkin at azul.com Wed May 19 20:28:10 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 19 May 2021 20:28:10 +0000 Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on Embedded VM In-Reply-To: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> Message-ID: Correct serviceability list address > On May 19, 2021, at 22:19, Sergey Nazarkin wrote: > > Hi! > > Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option. > > Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them. > > The bug affects jdk8 only [4]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8267426 > [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782 > [3] http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/ > [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413 > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mullan at openjdk.java.net Wed May 19 20:33:43 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 19 May 2021 20:33:43 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > adjust order of VM options The changes to the security tests look good. ------------- Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From vromero at openjdk.java.net Wed May 19 20:46:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 20:46:23 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v8] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06-07 Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From weijun at openjdk.java.net Wed May 19 21:56:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 21:56:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote: >> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is >> >> s = java.security.AccessController.doPrivileged( >> new GetPropertyAction("awt.image.redrawrate")); > > That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. > You can define a static private method to contain this and call it from the static initializer block. > Much better than applying the annotation to an entire class. > > --- a/src/java.desktop/share/classes/java/awt/Component.java > +++ b/src/java.desktop/share/classes/java/awt/Component.java > @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, > */ > static boolean isInc; > static int incRate; > + > + private static void initIncRate() { > + String s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.incrementaldraw")); > + isInc = (s == null || s.equals("true")); > + > + s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.redrawrate")); > + incRate = (s != null) ? Integer.parseInt(s) : 100; > + } > + > static { > /* ensure that the necessary native libraries are loaded */ > Toolkit.loadLibraries(); > @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, > if (!GraphicsEnvironment.isHeadless()) { > initIDs(); > } > - > - String s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.incrementaldraw")); > - isInc = (s == null || s.equals("true")); > - > - s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.redrawrate")); > - incRate = (s != null) ? Integer.parseInt(s) : 100; > + initIncRate(); > } Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 22:07:36 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 22:07:36 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote: >> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. >> You can define a static private method to contain this and call it from the static initializer block. >> Much better than applying the annotation to an entire class. >> >> --- a/src/java.desktop/share/classes/java/awt/Component.java >> +++ b/src/java.desktop/share/classes/java/awt/Component.java >> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, >> */ >> static boolean isInc; >> static int incRate; >> + >> + private static void initIncRate() { >> + String s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.incrementaldraw")); >> + isInc = (s == null || s.equals("true")); >> + >> + s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.redrawrate")); >> + incRate = (s != null) ? Integer.parseInt(s) : 100; >> + } >> + >> static { >> /* ensure that the necessary native libraries are loaded */ >> Toolkit.loadLibraries(); >> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, >> if (!GraphicsEnvironment.isHeadless()) { >> initIDs(); >> } >> - >> - String s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.incrementaldraw")); >> - isInc = (s == null || s.equals("true")); >> - >> - s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.redrawrate")); >> - incRate = (s != null) ? Integer.parseInt(s) : 100; >> + initIncRate(); >> } > > Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. I think it should all be taken care of as part of this proposed change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 22:17:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 22:17:34 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote: >> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. > > I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. > I think it should all be taken care of as part of this proposed change. I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 23:53:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 23:53:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote: >> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. >> I think it should all be taken care of as part of this proposed change. > > I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. I already pasted the patch for Component.java and it took about 60 seconds to do that. Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From david.holmes at oracle.com Thu May 20 00:50:16 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 10:50:16 +1000 Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on Embedded VM In-Reply-To: References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> Message-ID: Hi Sergey, Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test? Cheers, David On 20/05/2021 6:28 am, Sergey Nazarkin wrote: > Correct serviceability list address > > >> On May 19, 2021, at 22:19, Sergey Nazarkin wrote: >> >> Hi! >> >> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option. >> >> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them. >> >> The bug affects jdk8 only [4]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8267426 >> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782 >> [3] http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/ >> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413 >> >> >> >> > From cjplummer at openjdk.java.net Thu May 20 01:12:32 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 20 May 2021 01:12:32 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > 8263635: Add --servername option to jhsdb debugd src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 101: > 99: if (serverNamePrefix != null) { > 100: System.err.println("WARNING: sun.jvm.hotspot.rmi.serverNamePrefix is deprecated. Please specify it in --connect."); > 101: rmiObjectName = serverNamePrefix; If the servername was already specified with `--connect`, I would think that we would not want to override it with the property if it is also set. Maybe if both are set then fail with an error. Same in `getName()` below. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From cjplummer at openjdk.java.net Thu May 20 01:25:40 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 20 May 2021 01:25:40 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > 8263635: Add --servername option to jhsdb debugd src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 94: > 92: > 93: private static boolean debugdHelp() { > 94: System.out.println(" --serverid A unique identifier for this debug server."); "debugd server" instead of "debug server" src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 105: > 103: " 'java.rmi.server.hostname'. If not specified, the system property is used. If the system" + > 104: " property is not set, a system hostname is used."); > 105: System.out.println(" --servername Instance name of debugd server."); I think this should go right below `--serverid` above src/jdk.hotspot.agent/share/man/jhsdb.1 line 206: > 204: Sets the instance name of debugd server to distinguish SA debugee. > 205: It is used for RMI object name for server instance. > 206: If not specified, "SARemoteDebugger" will be set. "will be used" ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From weijun at openjdk.java.net Thu May 20 02:09:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:09:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote: >> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. > > Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, > and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. > I already pasted the patch for Component.java and it took about 60 seconds to do that. > Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. > > I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? I can make it a bug. I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Thu May 20 02:12:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:12:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote: >> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, >> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. >> I already pasted the patch for Component.java and it took about 60 seconds to do that. >> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. >> >> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? > > I can make it a bug. > > I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. > > And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. > > Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From ysuenaga at openjdk.java.net Thu May 20 03:03:09 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 20 May 2021 03:03:09 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4] In-Reply-To: References: Message-ID: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. > > serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. > And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3669/files - new: https://git.openjdk.java.net/jdk/pull/3669/files/03ed5d19..1315dc56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=02-03 Stats: 27 lines in 3 files changed: 16 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669 PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Thu May 20 03:05:31 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 20 May 2021 03:05:31 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v3] In-Reply-To: References: Message-ID: <9MhCTkA7i5VNb7WhTixLtxzN0cWBe6dkyB1F1PqYgpU=.b08c7ad1-ff72-4c19-8af7-205efa53a63e@github.com> On Sat, 15 May 2021 02:00:15 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > 8263635: Add --servername option to jhsdb debugd @plummercj Thanks for your review! I pushed new commit to fix them. And also I updated debugd help message in CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From prr at openjdk.java.net Thu May 20 04:08:38 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:08:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote: >> I can make it a bug. >> >> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. >> >> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. >> >> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. > > By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. That is unfortunate, but nonetheless I think required to be done. We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >From my point of view it is a blocker. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 20 04:25:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:25:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote: >> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. > > That is unfortunate, but nonetheless I think required to be done. > We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. > From my point of view it is a blocker. The JEP isn't PTT for 17 so there's plenty of time isn't there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From dholmes at openjdk.java.net Thu May 20 04:43:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 04:43:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Updates seem fine. Lucky _waiters was unused :) Will take another full pass over the changes. Thanks, David src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: protected: > 308: ObjectMonitor* _om; > 309: bool _exited; For consistency with raw monitor code this would _om_exited ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From lzang at openjdk.java.net Thu May 20 05:10:46 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 20 May 2021 05:10:46 GMT Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v25] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 11:55:12 GMT, Lin Zang wrote: >> 8252842: Extend jmap to support parallel heap dump > > Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - fix build issue after rebase and fix one issue > - Merge branch 'master' > - Merge branch 'master' into pd > - update copyright info > - Merge branch 'master' into par-dump > - undo JMap.java > - code refine and typo fix > - Merge branch 'master' into par-dump > - refine with several fix > - Merge branch 'master' into par-dump > - ... and 24 more: https://git.openjdk.java.net/jdk/compare/6ef46ce3...d03e994b Dear All, May I get more review about the PR? Thanks! BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/2261 From dholmes at openjdk.java.net Thu May 20 07:03:42 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 07:03:42 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Hi Robbin, Overall this looks good to me, but there is one issue that needs fixing (partially pre-existing but now also affecting ObjectMonitor::enter). Other minor comments below. Thanks, David src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236: > 234: > 235: template > 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition { Can we add a comment before this template definition please: // Perform a transition to _thread_blocked and take a call-back to be executed before // SafepointMechanism::process_if_requested when returning to the VM. This allows us // to perform an "undo" action if we might block processing a safepoint/handshake operation // (such as thread suspension). src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245: > 243: // Once we are blocked vm expects stack to be walkable > 244: thread->frame_anchor()->make_walkable(thread); > 245: thread->set_thread_state(_thread_blocked); This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this: `current->frame_anchor()->make_walkable(current);` `// Thread must be walkable before it is blocked.` `// Read in reverse order.` `OrderAccess::storestore();` `for (;;) {` ` current->set_thread_state(_thread_blocked);` src/hotspot/share/runtime/objectMonitor.cpp line 448: > 446: // Completed the tranisition. > 447: SafepointMechanism::process_if_requested(current); > 448: current->set_thread_state(_thread_in_vm); The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Thu May 20 07:03:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 07:03:43 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> References: <_3zFCGnOLqfo-7GnNh5ImorAQBzxIA-Mo0xiqHhVGgc=.90a9ad84-154b-4576-8f2d-fd28ec73c18c@github.com> Message-ID: On Mon, 17 May 2021 07:02:30 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48: >> >>> 46: // The rules are: >>> 47: // - We must never safepoint poll if raw monitor is owned. >>> 48: // - We may safepoint poll before it is owned and after it has been released. >> >> I'm not sure exactly what this is trying to say because user code can acquire a RawMonitor, then call into Java while holding the RawMonitor. That external use of RawMonitors should never cause any deadlock with the VMThread of course. > > This comment applies to the RawMonitor code, where the typical use-case that otherwise can deadlock is: > JavaThread: > -lock RM > LOOP { > -wait RM > -do stufff with data from VM thread > } > -unlock RM > > The user do not call into the VM/Java. > > VM Thread: > -safepoint > -lock RM > -notify RM > -unlock RM > > If we in this case safepoint between the lock and the unlock in wait() we deadlock with VM thread. > > If the user would call into the VM/Java while holding the RM he obviously could deadlock with VM thread. > But he would also deadlock if he used a pthread mutex because that code would be buggy. Okay I understand what you are referring to now - thanks. It is a bit concerning that Raw Monitor wait is specified to be callback safe as that means we can legitimately block the VMThread indefinitely! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From alanb at openjdk.java.net Thu May 20 07:08:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 May 2021 07:08:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >> From my point of view it is a blocker. > > The JEP isn't PTT for 17 so there's plenty of time isn't there ? There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From rehn at openjdk.java.net Thu May 20 07:10:34 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:10:34 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > Just one more, rather unimportant comment... > > Either way: LGTM! > > Thanks, Richard. Thanks! > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > >> 380: >> 381: _recursions = 0; >> 382: ret = simple_wait(self, millis); > > IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. > > In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. > > _recursions = 0; > ret = simple_wait(self, millis); > _recursions = save; Yes, it can be re-written as something below, but is this more readable? _recursions = 0; ret = simple_wait(self, millis); if (self->is_Java_thread()) { // JavaThread re-enter JavaThread* jt = self->as_Java_thread(); { ThreadInVMfromNative tivmfn(jt); for (;;) { ExitOnSuspend eos(this); { ThreadBlockInVMPreprocess tbivmp(jt, eos); simple_enter(jt); } if (!eos.monitor_exited()) { break; } } if (jt->is_interrupted(true)) { ret = M_INTERRUPTED; } } } else { // Non-JavaThread re-enter assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); simple_enter(self); } _recursions = save; ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From david.holmes at oracle.com Thu May 20 07:19:03 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 17:19:03 +1000 Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> Message-ID: <892486cc-4564-81e1-b3d8-2922859c78e8@oracle.com> On 20/05/2021 5:10 pm, Robbin Ehn wrote: > On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > >> Just one more, rather unimportant comment... >> >> Either way: LGTM! >> >> Thanks, Richard. > > Thanks! > >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: >> >>> 380: >>> 381: _recursions = 0; >>> 382: ret = simple_wait(self, millis); >> >> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. >> >> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. >> >> _recursions = 0; >> ret = simple_wait(self, millis); >> _recursions = save; > > Yes, it can be re-written as something below, but is this more readable? I'd say yes with two minor modifications: > > _recursions = 0; > ret = simple_wait(self, millis); + // Now we need to re-enter the monitor. For JavaThread's + // we need to manage suspend requests. > if (self->is_Java_thread()) { // JavaThread re-enter > JavaThread* jt = self->as_Java_thread(); > { I think this extra block scope can also go. Cheers, David ----- > ThreadInVMfromNative tivmfn(jt); > for (;;) { > ExitOnSuspend eos(this); > { > ThreadBlockInVMPreprocess tbivmp(jt, eos); > simple_enter(jt); > } > if (!eos.monitor_exited()) { > break; > } > } > if (jt->is_interrupted(true)) { > ret = M_INTERRUPTED; > } > } > } else { // Non-JavaThread re-enter > assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); > simple_enter(self); > } > _recursions = save; > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3875 > From rehn at openjdk.java.net Thu May 20 07:19:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:19:35 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Thu, 20 May 2021 05:14:43 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 236: > >> 234: >> 235: template >> 236: class ThreadBlockInVMPreprocess : public ThreadStateTransition { > > Can we add a comment before this template definition please: > > // Perform a transition to _thread_blocked and take a call-back to be executed before > // SafepointMechanism::process_if_requested when returning to the VM. This allows us > // to perform an "undo" action if we might block processing a safepoint/handshake operation > // (such as thread suspension). Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 245: > >> 243: // Once we are blocked vm expects stack to be walkable >> 244: thread->frame_anchor()->make_walkable(thread); >> 245: thread->set_thread_state(_thread_blocked); > > This is a pre-existing issue. Everywhere we call make_walkable and then call plain set_thread_state (other than on PPC/Aarch64 which do a release_store) we are at risk of the thread_state update being reordered with stores related to making the stack walkable. Potentially allowing the VMThread (or other thread) to walk a stack that is not yet walkable! The original ObjectMonitor::enter code was aware of this: > `current->frame_anchor()->make_walkable(current);` > `// Thread must be walkable before it is blocked.` > `// Read in reverse order.` > `OrderAccess::storestore();` > `for (;;) {` > ` current->set_thread_state(_thread_blocked);` Good catch, fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: protected: >> 308: ObjectMonitor* _om; >> 309: bool _exited; > > For consistency with raw monitor code this would be _om_exited Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 07:31:38 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:31:38 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 07:22:06 GMT, Robbin Ehn wrote: > Hi Robbin, > > Sorry for the delay in getting through this. > > Overall approach looks good. I have a few queries below and some requested naming changes to make things clearer. > > Thanks, > David Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 07:31:41 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 07:31:41 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Thu, 20 May 2021 06:03:28 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/runtime/objectMonitor.cpp line 448: > >> 446: // Completed the tranisition. >> 447: SafepointMechanism::process_if_requested(current); >> 448: current->set_thread_state(_thread_in_vm); > > The comment block above this code is no longer accurate as there is no longer an opportunity to go to a safepoint at the end of the block. I'm not sure what a thread dump would show with the new code. I moved comment and current->set_current_pending_monitor(NULL); into loop. And I set current->set_current_pending_monitor(om); to OM again in ExitOnSuspend if we exit the OM. The thread dump is then identical to what we have today if ~ThreadBlockInVMPreprocess safepoints. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From vromero at openjdk.java.net Thu May 20 09:14:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 May 2021 09:14:33 GMT Subject: Integrated: 8260517: implement Sealed Classes as a standard feature in Java In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. This pull request has now been integrated. Changeset: 0fa9223f Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b Stats: 444 lines in 54 files changed: 51 ins; 275 del; 118 mod 8260517: implement Sealed Classes as a standard feature in Java Co-authored-by: Harold Seigel Co-authored-by: Vicente Romero Reviewed-by: dholmes, mcimadamore, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From snazarkin at azul.com Thu May 20 10:27:21 2021 From: snazarkin at azul.com (Sergey Nazarkin) Date: Thu, 20 May 2021 10:27:21 +0000 Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on Embedded VM In-Reply-To: References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> Message-ID: <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com> Thanks David, I?ve tagged the bug The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays. /Sergey > On May 20, 2021, at 03:50, David Holmes wrote: > > Hi Sergey, > > Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test? > > Cheers, > David > > > On 20/05/2021 6:28 am, Sergey Nazarkin wrote: >> Correct serviceability list address >>> On May 19, 2021, at 22:19, Sergey Nazarkin wrote: >>> >>> Hi! >>> >>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option. >>> >>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them. >>> >>> The bug affects jdk8 only [4]. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426 >>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782 >>> [3] http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/ >>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413 >>> >>> >>> >>> From rehn at openjdk.java.net Thu May 20 11:37:35 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:37:35 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> <-p9VRG0Mk9CJ9p9IJregLJ0PBeRIwg2WNP-nvFn4Jz8=.e34b8f31-3d98-4bf5-9965-71908a0d63b8@github.com> Message-ID: On Thu, 20 May 2021 07:07:20 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: >> >>> 380: >>> 381: _recursions = 0; >>> 382: ret = simple_wait(self, millis); >> >> IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. >> >> In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. >> >> _recursions = 0; >> ret = simple_wait(self, millis); >> _recursions = save; > > Yes, it can be re-written as something below, but is this more readable? > > > _recursions = 0; > ret = simple_wait(self, millis); > > if (self->is_Java_thread()) { // JavaThread re-enter > JavaThread* jt = self->as_Java_thread(); > { > ThreadInVMfromNative tivmfn(jt); > for (;;) { > ExitOnSuspend eos(this); > { > ThreadBlockInVMPreprocess tbivmp(jt, eos); > simple_enter(jt); > } > if (!eos.monitor_exited()) { > break; > } > } > if (jt->is_interrupted(true)) { > ret = M_INTERRUPTED; > } > } > } else { // Non-JavaThread re-enter > assert(ret != M_INTERRUPTED, "Only JavaThreads can be interrupted"); > simple_enter(self); > } > _recursions = save; Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 11:42:06 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:42:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Review fixes 2 - Merge branch 'master' into 8265753 - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/a8b8469c..6faf1422 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=03-04 Stats: 4768 lines in 204 files changed: 3182 ins; 1013 del; 573 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Thu May 20 11:42:13 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 20 May 2021 11:42:13 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v4] In-Reply-To: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> References: <_p2l24SBO994uiPhp3j1fS_CmLLwGxfgBg_99MVnzXE=.94e13d44-2b7d-4744-a5bf-c0b921639dec@github.com> Message-ID: On Wed, 19 May 2021 07:26:14 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_ > > On 20/05/2021 5:10 pm, Robbin Ehn wrote: > > > On Wed, 19 May 2021 14:25:41 GMT, Richard Reingruber wrote: > > > Just one more, rather unimportant comment... > > > Either way: LGTM! > > > Thanks, Richard. > > > > > > Thanks! > > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 382: > > > > 380: > > > > 381: _recursions = 0; > > > > 382: ret = simple_wait(self, millis); > > > > > > > > > IMHO the guarantee at L379 is redundant with the newly added identical guarantee in `JvmtiRawMonitor::simple_wait()` at L240. > > > In case you agree to remove the guarantee, I don't see why the following statements cannot be pulled out of the if-statement. > > > ``` > > > _recursions = 0; > > > ret = simple_wait(self, millis); > > > _recursions = save; > > > ``` > > > > > > Yes, it can be re-written as something below, but is this more readable? > > I'd say yes with two minor modifications: > > > _recursions = 0; > > ret = simple_wait(self, millis); > > + // Now we need to re-enter the monitor. For JavaThread's > + // we need to manage suspend requests. > > > if (self->is_Java_thread()) { // JavaThread re-enter > > JavaThread* jt = self->as_Java_thread(); > > { > > I think this extra block scope can also go. > > Cheers, > David > ----- Fixed, thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stefank at openjdk.java.net Thu May 20 12:03:00 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 20 May 2021 12:03:00 GMT Subject: RFR: 8267464: Circular-dependency resiliant inline headers Message-ID: I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. This is a small, contrived example to show the problem: // a.hpp #pragma once void a1(); void a2(); // a.inline.hpp #pragma once #include "a.hpp" #include "b.inline.hpp" inline void a1() { b1(); } inline void a2() { } // b.hpp #pragma once void b1(); void b2(); // b.inline.hpp #pragma once #include "a.inline.hpp" #include "b.hpp" inline void b1() { } inline void b2() { a1(); } The following code compiles fine: // a.cpp #include "a.inline.hpp" int main() { a1(); return 0; } But the following: // b.cpp #include "b.inline.hpp" int main() { b1(); return 0; } fails with the this error message: In file included from b.inline.hpp:3, from b.cpp:1: a.inline.hpp: In function ?void a1()?: a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? We can see the problem with g++ -E: # 1 "a.inline.hpp" 1 # 1 "a.hpp" 1 void a1(); void a2(); # 4 "a.inline.hpp" 2 inline void a1() { b1(); } inline void a2() { } # 4 "b.inline.hpp" 2 # 1 "b.hpp" 1 void b1(); void b2(); # 5 "b.inline.hpp" 2 inline void b1() { } inline void b2() { a1(); } # 2 "b.cpp" 2 int main() { b1(); return 0; } b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. In the example above, b.inline.hpp would become: // b.inline.hpp #pragma once #include "b.hpp" #include "a.inline.hpp" inline void b1() { } inline void b2() { a1(); } and now both a.cpp and b.cpp compiles. The generated output now looks like this: # 1 "b.inline.hpp" 1 # 1 "b.hpp" 1 void b1(); void b2(); # 4 "b.inline.hpp" 2 # 1 "a.inline.hpp" 1 # 1 "a.hpp" 1 void a1(); void a2(); # 4 "a.inline.hpp" 2 inline void a1() { b1(); } inline void a2() { } # 5 "b.inline.hpp" 2 inline void b1() { } inline void b2() { a1(); } # 2 "b.cpp" 2 int main() { b1(); return 0; } The declarations come first, and the compiler is happy. An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. Some notes about this patch: 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. What do you think? ------------- Commit messages: - 8267464: Circular-dependency resiliant inline headers Changes: https://git.openjdk.java.net/jdk/pull/4127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267464 Stats: 459 lines in 224 files changed: 350 ins; 104 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From david.holmes at oracle.com Thu May 20 13:35:41 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 23:35:41 +1000 Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on Embedded VM In-Reply-To: <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com> References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com> Message-ID: On 20/05/2021 8:27 pm, Sergey Nazarkin wrote: > Thanks David, I?ve tagged the bug > > The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays. Looks like the test got a major overhaul after JDK 8 was released. That may be when it stopped working with SE Embedded. Or it may be we used to run the tests such that -XX:+UsePerfData was passed by jtreg ... I don't recall now. :) Cheers, David > > /Sergey > >> On May 20, 2021, at 03:50, David Holmes wrote: >> >> Hi Sergey, >> >> Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test? >> >> Cheers, >> David >> >> >> On 20/05/2021 6:28 am, Sergey Nazarkin wrote: >>> Correct serviceability list address >>>> On May 19, 2021, at 22:19, Sergey Nazarkin wrote: >>>> >>>> Hi! >>>> >>>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option. >>>> >>>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them. >>>> >>>> The bug affects jdk8 only [4]. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426 >>>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782 >>>> [3] http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/ >>>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413 >>>> >>>> >>>> >>>> > From sspitsyn at openjdk.java.net Thu May 20 18:24:29 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 20 May 2021 18:24:29 GMT Subject: RFR: 8266967: debug.cpp utility find() should print Java Object fields. [v2] In-Reply-To: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com> References: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com> Message-ID: On Thu, 13 May 2021 13:24:17 GMT, Kevin Walls wrote: >> This change enables debug.cpp's find() utility to print Java Objects with their fields. >> >> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on. >> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work. >> >> >> Checking other uses of os::print_location this might affect: >> >> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64 >> which use os::print_location to print register contents and print words at top of stack. >> These will be more verbose, as it already is in non-PRODUCT builds. >> >> vmError uses os::print_location when showing the stack, i.e. this output: >> >> Stack slot to memory mapping: >> stack at sp + 0 slots: 0x0000000000000002 is an unknown value >> ..etc... >> >> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show). >> >> >> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes. >> >> >> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only: >> >> "Executing find" >> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader >> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader' >> >> ...then with the change the full info: >> >> "Executing find" >> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader >> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader' >> - ---- fields (total size 13 words): >> - private 'defaultAssertionStatus' 'Z' @12 false >> - private final 'parent' 'Ljava/lang/ClassLoader;' @24 a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a >> 40} (ff0a0a40) >> - private final 'name' 'Ljava/lang/String;' @28 "app"{0x00000000ff0d0060} (ff0d0060) >> - private final 'unnamedModule' 'Ljava/lang/Module;' @32 a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448) >> ...etc... > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > ifdef correction Hi Kevin, The fix looks okay to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4011 From aivanov at openjdk.java.net Thu May 20 18:28:41 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 20 May 2021 18:28:41 GMT Subject: RFR: 8260690: JConsole User Guide Link from the Help menu is not accessible by keyboard In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar wrote: > Hi All, > > Could you please review this JConsole fix for JDK-17? > > Problem: > JConsole User Guide Link from the Help menu is not accessible by keyboard. > > Fix: > The JConsole User Guide Link can be highlighted and can now be accessed using keyboard. > > Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3587 From kcr at openjdk.java.net Thu May 20 18:31:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 18:31:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com> On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine. I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/4073 From dholmes at openjdk.java.net Thu May 20 22:09:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 20 May 2021 22:09:39 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 11:42:06 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Updates mostly good but still a storestore issue to resolve. Thanks, David src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379: > 377: ret = simple_wait(self, millis); > 378: > 379: // Now we need to re-enter the monitor. For JavaThread's My bad: no apostrophe in JavaThreads src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > 210: _thread->frame_anchor()->make_walkable(_thread); > 211: OrderAccess::storestore(); > 212: _thread->set_thread_state(_thread_in_native); Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From cjplummer at openjdk.java.net Fri May 21 01:17:36 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 21 May 2021 01:17:36 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4] In-Reply-To: References: Message-ID: <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com> On Thu, 20 May 2021 03:03:09 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 133: > 131: name = serverNamePrefix; > 132: } else { > 133: throw new DebuggerException("Cannot set both sun.jvm.hotspot.rmi.serverNamePrefix and in --servername together"); Remove "in" ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Fri May 21 01:45:59 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 21 May 2021 01:45:59 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5] In-Reply-To: References: Message-ID: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. > > serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. > And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3669/files - new: https://git.openjdk.java.net/jdk/pull/3669/files/1315dc56..19d1f565 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3669&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3669/head:pull/3669 PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Fri May 21 01:46:00 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 21 May 2021 01:46:00 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v4] In-Reply-To: <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com> References: <494YNA8YL_sAQGeq__piQp3cqbvwQW-rkV_UoqIIbqY=.99c2b2b5-861b-428c-9bbd-6bf44d350cce@github.com> Message-ID: On Fri, 21 May 2021 01:14:21 GMT, Chris Plummer wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/RMIHelper.java line 133: > >> 131: name = serverNamePrefix; >> 132: } else { >> 133: throw new DebuggerException("Cannot set both sun.jvm.hotspot.rmi.serverNamePrefix and in --servername together"); > > Remove "in" Thanks! I fixed it in new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From cjplummer at openjdk.java.net Fri May 21 01:52:32 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 21 May 2021 01:52:32 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5] In-Reply-To: References: Message-ID: <_3yS7PWHuyTyLxB_7A6UT2_pghY9-pPdrUehWuCW0LE=.e276f49c-3066-469a-b486-e4dbf637d758@github.com> On Fri, 21 May 2021 01:45:59 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From weijun at openjdk.java.net Fri May 21 01:58:47 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 01:58:47 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K Message-ID: The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4073 Commit messages: - 8267521: Post JEP 411 refactoring: maximum covering > 50K Changes: https://git.openjdk.java.net/jdk/pull/4138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267521 Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/4138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138 PR: https://git.openjdk.java.net/jdk/pull/4138 From rehn at openjdk.java.net Fri May 21 08:49:43 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 21 May 2021 08:49:43 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 21:51:31 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Review fixes 2 >> - Merge branch 'master' into 8265753 >> - Review fixes >> - Merge branch 'master' into 8265753 >> - Fixes for Dan >> - Merge branch 'master' into 8265753 >> - Removed manual transitions > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 379: > >> 377: ret = simple_wait(self, millis); >> 378: >> 379: // Now we need to re-enter the monitor. For JavaThread's > > My bad: no apostrophe in JavaThreads Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > >> 210: _thread->frame_anchor()->make_walkable(_thread); >> 211: OrderAccess::storestore(); >> 212: _thread->set_thread_state(_thread_in_native); > > Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? > But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. But we have more of those. Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). So yes it should always be there, good RFE! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stefank at openjdk.java.net Fri May 21 09:11:09 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 21 May 2021 09:11:09 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2] In-Reply-To: References: Message-ID: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Clean up assembler_.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4127/files - new: https://git.openjdk.java.net/jdk/pull/4127/files/6f3fe6af..260c1115 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=00-01 Stats: 45 lines in 28 files changed: 3 ins; 24 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From dmarkov at openjdk.java.net Fri May 21 09:38:30 2021 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Fri, 21 May 2021 09:38:30 GMT Subject: RFR: 8260690: JConsole User Guide Link from the Help menu is not accessible by keyboard In-Reply-To: References: Message-ID: <30zElBoKee8iq1kkmw2R3Ks9NQFSEGJWhxRjG2crKVs=.b64f78ee-cb8f-4f18-8423-f73bc89cb78a@github.com> On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar wrote: > Hi All, > > Could you please review this JConsole fix for JDK-17? > > Problem: > JConsole User Guide Link from the Help menu is not accessible by keyboard. > > Fix: > The JConsole User Guide Link can be highlighted and can now be accessed using keyboard. > > Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link. Marked as reviewed by dmarkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3587 From rehn at openjdk.java.net Fri May 21 09:41:10 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 21 May 2021 09:41:10 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Final fixes: last famous words ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/6faf1422..cc15431e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=04-05 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From github.com+70650887+skodanda at openjdk.java.net Fri May 21 09:45:39 2021 From: github.com+70650887+skodanda at openjdk.java.net (K Suman Rajkumaar) Date: Fri, 21 May 2021 09:45:39 GMT Subject: Integrated: 8260690: JConsole User Guide Link from the Help menu is not accessible by keyboard In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 11:02:50 GMT, K Suman Rajkumaar wrote: > Hi All, > > Could you please review this JConsole fix for JDK-17? > > Problem: > JConsole User Guide Link from the Help menu is not accessible by keyboard. > > Fix: > The JConsole User Guide Link can be highlighted and can now be accessed using keyboard. > > Using the TAB key, the link can be highlighted and ENTER or SPACE key will browse the link. This pull request has now been integrated. Changeset: b5d32bbf Author: K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com> Committer: Dmitry Markov URL: https://git.openjdk.java.net/jdk/commit/b5d32bbfc716870904e91ce07a09f08929f2563e Stats: 122 lines in 1 file changed: 108 ins; 0 del; 14 mod 8260690: JConsole User Guide Link from the Help menu is not accessible by keyboard Reviewed-by: aivanov, dmarkov ------------- PR: https://git.openjdk.java.net/jdk/pull/3587 From weijun at openjdk.java.net Fri May 21 14:00:39 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 14:00:39 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2] In-Reply-To: References: Message-ID: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: typo on windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4138/files - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138 PR: https://git.openjdk.java.net/jdk/pull/4138 From ayang at openjdk.java.net Fri May 21 14:31:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 21 May 2021 14:31:12 GMT Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer Message-ID: Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. ------------- Commit messages: - alias map - second - first Changes: https://git.openjdk.java.net/jdk/pull/4146/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4146&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267468 Stats: 45 lines in 4 files changed: 2 ins; 0 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/4146.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4146/head:pull/4146 PR: https://git.openjdk.java.net/jdk/pull/4146 From dfuchs at openjdk.java.net Fri May 21 15:36:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 May 2021 15:36:08 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java src/java.base/share/classes/java/lang/SecurityManager.java line 104: > 102: * method will throw an {@code UnsupportedOperationException}). If the > 103: * {@systemProperty java.security.manager} system property is set to the > 104: * special token "{@code allow}", then a security manager will not be set at Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From dfuchs at openjdk.java.net Fri May 21 15:55:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 May 2021 15:55:07 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > typo on windows src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120: > 118: vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue(); > 119: return System.getProperty("file.encoding", "ISO8859_1"); > 120: } It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK. src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550: > 548: * @throws IOException if the connection was unsuccessful. > 549: */ > 550: @SuppressWarnings("removal") Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method? src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921: > 919: } > 920: > 921: @SuppressWarnings("removal") Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda... PrivilegedAction pa = () -> new Socket(proxy); @SuppressWarnings("removal") var ps = AccessController.doPrivileged(pa); s = ps; ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From sgehwolf at openjdk.java.net Fri May 21 16:16:18 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 21 May 2021 16:16:18 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v2] In-Reply-To: <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com> References: <9VBZqwiHrAzT_UHPsv2gIiGsSq9csV8cFOfjmgmhEwg=.50ae512b-5705-4c63-85ea-01f861e78024@github.com> Message-ID: On Tue, 11 May 2021 14:57:32 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with one additional commit since the last revision: > > cpu.shares for OperatingSystemImpl.getCpuLoad() @tanghaoth90 I've added a comment which should address the cpu shares based cpuLoad problem. Let me know what you think. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Fri May 21 16:16:19 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 21 May 2021 16:16:19 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v2] In-Reply-To: References: Message-ID: <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com> On Tue, 11 May 2021 15:48:43 GMT, Hao Tang wrote: >>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case. >> >> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation. >> >> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways. >> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` & `share`); >> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number. >> >> Looking forward to your suggestion. > >> @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still). > > @jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example. > > 1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of > > long usageNanos = containerMetrics.getCpuUsage(); > > is an accumulated CPU usage rather than a real-time CPU usage. > According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue. > > 2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`. > > Any suggestion is appreciated. @jerboaa @argha-c @tanghaoth90 As to your observation of 1). Yes, that's true and I'm not sure it's worth changing. We could change the javadoc. As for 2) I've created a PR for your branch with a suggested implementation for cpu shares based accounting. It uses a similar heuristics than the getCpuLoad0() uses here: https://github.com/openjdk/jdk/blob/master/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L278 That's the best I could think of. It's certainly more accurate than the current implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From prr at openjdk.java.net Fri May 21 18:03:01 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 18:03:01 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote: >> The JEP isn't PTT for 17 so there's plenty of time isn't there ? > > There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way. It is very straight forward to run the automated tests across all platforms these days. I get the impression that no one is guaranteeing to do this straight after integration. It sounds like it is up for deferral if time runs out. The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound like this JEP is nearly as done as first presented. If there was some expectation that groups responsible for an area would get involved with this issue which I am assured was already known about, then why was it not raised before and made part of the plan ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Fri May 21 18:31:01 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 18:31:01 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote: >> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). >> >> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). >> >> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: >> >> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. >> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. >> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. >> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. >> >> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. >> >> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. >> >> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. >> >> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). >> >> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). >> >> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: >> >> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) >> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) >> ``` >> >> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > adjust order of VM options The client changes are fine except for the one misplaced (c) test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3: > 1: /* > 2: * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Probably the (c) update was meant to be on the .sh file that is actually modified. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4071 From simonis at openjdk.java.net Fri May 21 19:29:17 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 21 May 2021 19:29:17 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 Message-ID: In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: // Copy the "source file name" attribute from new class version the_class->set_source_file_name_index( scratch_class->source_file_name_index()); Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? ------------- Commit messages: - 8267555: Fix class file version during redefinition after 8238048 Changes: https://git.openjdk.java.net/jdk/pull/4149/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267555 Stats: 258 lines in 6 files changed: 251 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4149/head:pull/4149 PR: https://git.openjdk.java.net/jdk/pull/4149 From weijun at openjdk.java.net Fri May 21 19:50:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 19:50:15 GMT Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v2] In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com> Message-ID: On Fri, 21 May 2021 18:26:48 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust order of VM options > > test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3: > >> 1: /* >> 2: * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > Probably the (c) update was meant to be on the .sh file that is actually modified. Oops, I'll back it out. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Fri May 21 20:01:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:01:15 GMT Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v3] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: feedback from Phil reverted: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Fri May 21 20:18:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:18:58 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2] In-Reply-To: References: Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com> On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120: > >> 118: vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue(); >> 119: return System.getProperty("file.encoding", "ISO8859_1"); >> 120: } > > It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK. You might say we thus avoid wasting the return value, as much as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Fri May 21 20:23:14 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:23:14 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> typo on windows > > src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550: > >> 548: * @throws IOException if the connection was unsuccessful. >> 549: */ >> 550: @SuppressWarnings("removal") > > Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method? I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Fri May 21 20:37:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:37:30 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update FtpClient.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4138/files - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02 Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138 PR: https://git.openjdk.java.net/jdk/pull/4138 From prr at openjdk.java.net Fri May 21 20:46:03 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 20:46:03 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > 57: ProcessCommunicator > 58: .executeChildProcess(Consumer.class, new String[0]); > 59: if (!"Hello".equals(processResults.getStdOut())) { Who or what prompted this change ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Fri May 21 20:55:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:55:02 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote: > I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed > > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > > > 57: ProcessCommunicator > > 58: .executeChildProcess(Consumer.class, new String[0]); > > 59: if (!"Hello".equals(processResults.getStdOut())) { > > Who or what prompted this change ? I replied right in the thread but unfortunately GitHub does not display it at the end of page. This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From kbarrett at openjdk.java.net Sat May 22 05:53:59 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 22 May 2021 05:53:59 GMT Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4146 From alanb at openjdk.java.net Sat May 22 07:00:03 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 22 May 2021 07:00:03 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way. > It is very straight forward to run the automated tests across all platforms these days. > I get the impression that no one is guaranteeing to do this straight after integration. > It sounds like it is up for deferral if time runs out. > > The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound > like this JEP is nearly as done as first presented. > > If there was some expectation that groups responsible for an area would get involved with this > issue which I am assured was already known about, then why was it not raised before and made > part of the plan ? Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR. PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From github.com+7947546+tanghaoth90 at openjdk.java.net Sun May 23 07:08:13 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Sun, 23 May 2021 07:08:13 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v3] In-Reply-To: References: Message-ID: > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". Hao Tang has updated the pull request incrementally with one additional commit since the last revision: Add cpuLoad implementation for cpu shares quota ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3656/files - new: https://git.openjdk.java.net/jdk/pull/3656/files/81867f21..d76fd441 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=01-02 Stats: 79 lines in 4 files changed: 74 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From mullan at openjdk.java.net Sun May 23 16:40:59 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Sun, 23 May 2021 16:40:59 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.base/share/classes/java/lang/SecurityManager.java line 104: > >> 102: * method will throw an {@code UnsupportedOperationException}). If the >> 103: * {@systemProperty java.security.manager} system property is set to the >> 104: * special token "{@code allow}", then a security manager will not be set at > > Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From kbarrett at openjdk.java.net Mon May 24 00:17:01 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 24 May 2021 00:17:01 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2] In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> References: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> Message-ID: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com> On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Clean up assembler_.inline.hpp Code changes look fine. This needs an update to the style guide too. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4127 From dholmes at openjdk.java.net Mon May 24 02:10:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 02:10:58 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 08:45:29 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: >> >>> 210: _thread->frame_anchor()->make_walkable(_thread); >>> 211: OrderAccess::storestore(); >>> 212: _thread->set_thread_state(_thread_in_native); >> >> Can't help but think the ppc/aarch64 folk have it right and that set_thread_state should always (?) have release semantics - and would then be renamed release_set_thread_state(). Also avoids a double barrier on ppc/aarch64. Followup RFE? >> But note that we need the storestore after all the make_walkable's that are followed by set_thread_state. > > Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. > But we have more of those. > > Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. > Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). > So yes it should always be there, good RFE! Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Mon May 24 02:33:03 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 24 May 2021 02:33:03 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 02:08:43 GMT, David Holmes wrote: >> Ah, you mean the pre-exiting missing of a storestore in TBIVM? Fixed. >> But we have more of those. >> >> Note that on TSO it's not needed, since both are volatile and will not be re-ordered by compiler. >> Yes, the platform which actually do care about avoiding release for performance have it (because it's needed). >> So yes it should always be there, good RFE! > > Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. > > Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. > > Thanks, > David I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion. The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 24 06:46:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 06:46:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: <0JV9oMEZMPk-NIIsIQXvsQwCz1gbs40NtHLARinkI68=.4c4ad9b7-6cca-4e39-83c4-869bbe2853aa@github.com> On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Final fixes: last famous words Are we good to go? Thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Mon May 24 06:46:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 24 May 2021 06:46:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 02:29:23 GMT, David Holmes wrote: >> Okay I will file a RFE to get the memory ordering semantics of set_thread_state cleaned up so we don't have any missing barriers where needed, nor redundant barriers. >> >> Note that the expectation is that we write the code for the loosest possible memory model with all barriers expressed in the code, and it is then up to the implementation of those barriers to reduce it to nothing if not needed on a given platform. >> >> Thanks, >> David > > I have filed JDK-8267585, but I realize now what you are saying. The existing code handles the barrier inconsistently. In most places it is only inside set_thread_state, for those platforms that need it. Elsewhere it is explicit in the code that calls set_thread_state - which leads to redundant barriers on the platforms that need them. I mistakenly flagged the implicit cases as a bug based on the existence of the explicit cases - but that is not the case. Sorry for the confusion. > > The additional storestore barriers you added before the call to set_thread_state can be removed, and I will tidy this up using the new RFE. > > Thanks, > David Sounds good, thank. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From eosterlund at openjdk.java.net Mon May 24 08:37:11 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 24 May 2021 08:37:11 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2] In-Reply-To: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> References: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> Message-ID: On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Clean up assembler_.inline.hpp Looks great! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4127 From dfuchs at openjdk.java.net Mon May 24 09:03:10 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 May 2021 09:03:10 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4138 From stefank at openjdk.java.net Mon May 24 12:14:10 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 24 May 2021 12:14:10 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v3] In-Reply-To: References: Message-ID: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson 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 remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Clean up assembler_.inline.hpp - 8267464: Circular-dependency resiliant inline headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4127/files - new: https://git.openjdk.java.net/jdk/pull/4127/files/260c1115..4bcd4348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=01-02 Stats: 5145 lines in 153 files changed: 2603 ins; 1960 del; 582 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From stefank at openjdk.java.net Mon May 24 12:14:10 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 24 May 2021 12:14:10 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v2] In-Reply-To: <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com> References: <2umZkQrx2-G55b24P-HV35dWJ84VMaumFaNizjpNw_k=.27e4e0b0-1aef-4867-a49b-903f9b860bec@github.com> <6K69ZSv9jA-M9nRoeCAkw-PygKL2GVUg30NqfI0wbwo=.b082724d-986d-4bbb-8bd0-175200f3031f@github.com> Message-ID: On Mon, 24 May 2021 00:14:06 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up assembler_.inline.hpp > > Code changes look fine. This needs an update to the style guide too. Thanks @kimbarrett and @fisk for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From stefank at openjdk.java.net Mon May 24 12:58:45 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 24 May 2021 12:58:45 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4] In-Reply-To: References: Message-ID: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Update HotSpot style guide documents ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4127/files - new: https://git.openjdk.java.net/jdk/pull/4127/files/4bcd4348..ba9ad1b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=02-03 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From weijun at openjdk.java.net Mon May 24 13:53:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 13:53:34 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: keep only one systemProperty tag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 24 13:53:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 13:53:37 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 104: >> >>> 102: * method will throw an {@code UnsupportedOperationException}). If the >>> 103: * {@systemProperty java.security.manager} system property is set to the >>> 104: * special token "{@code allow}", then a security manager will not be set at >> >> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. > > Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too. New commit pushed. There is only one `@systemProperty` tag now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 24 14:05:08 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 14:05:08 GMT Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager [v4] In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. Weijun Wang 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 20 additional commits since the last revision: - Merge branch 'master' into 8267184 - feedback from Phil reverted: - adjust order of VM options - test for awt - test for hotspot-gc - test for compiler - test for net - test for core-libs - test for beans - test for xml - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4071/files - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03 Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod Patch: https://git.openjdk.java.net/jdk/pull/4071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071 PR: https://git.openjdk.java.net/jdk/pull/4071 From weijun at openjdk.java.net Mon May 24 17:02:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 17:02:13 GMT Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com> Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com> On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()` need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests). > > To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks: > > 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label. > 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit. > 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit. > 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit. > > Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict. > > Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9. > > Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line. > > There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test). > > 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611). > > 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`: > > rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%) > rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%) > ``` > > The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073. This pull request has now been integrated. Changeset: 640a2afd Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7 Stats: 1028 lines in 852 files changed: 252 ins; 9 del; 767 mod 8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/4071 From dcubed at openjdk.java.net Mon May 24 18:25:06 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 24 May 2021 18:25:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 09:41:10 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Final fixes: last famous words Thumbs up. I just have some minor questions about a couple of the details. Nothing blocking. src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405: > 403: > 404: guarantee(self == _owner, "invariant"); > 405: guarantee(save == _recursions, "invariant"); Since you just restored the `_recursions` field on L402, why do you need this guarantee() 2 code lines later? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > 210: _thread->frame_anchor()->make_walkable(_thread); > 211: OrderAccess::storestore(); > 212: _thread->set_thread_state(_thread_in_native); Please add a comment to the `storestore()` call: // Keep thread_state change and make_walkable() separate. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251: > 249: thread->frame_anchor()->make_walkable(thread); > 250: OrderAccess::storestore(); > 251: thread->set_thread_state(_thread_blocked); Please add a comment to the storestore() call: // Keep thread_state change and make_walkable() separate. src/hotspot/share/runtime/objectMonitor.cpp line 435: > 433: ThreadBlockInVMPreprocess tbivs(current, eos); > 434: EnterI(current); > 435: current->set_current_pending_monitor(NULL); `current->set_current_pending_monitor(this)` is called above on L413 which is before the `for(;;)` loop so after this call to clear the pending monitor, if we loop again, we will no longer have a pending monitor set. That's a change in behavior from when the pending monitor was set to NULL on old L435 below. I'm not sure why you move the code from old L435 (outside the loop) to new L435 (inside the loop). Update: I found this resolved comment below: > And I set current->set_current_pending_monitor(om); to OM again > in ExitOnSuspend if we exit the OM. so that explains why we don't have a big change in behavior. src/hotspot/share/runtime/objectMonitor.cpp line 451: > 449: // We cleared the pending monitor info since we've just gotten past > 450: // the enter-check-for-suspend dance and we now own the monitor free > 451: // and clear, i.e., it is no longer pending. This comment explains why the set-pending-to-NULL code was here (outside the loop). You moved the code, but now the comment is misplaced and the code no longer works the same. Update: I found this resolved comment below: And I set current->set_current_pending_monitor(om); to OM again in ExitOnSuspend if we exit the OM. so that explains why we don't have a big change in behavior. However, I think you still need to do something about this comment. There is still an observable change in behavior in that the current pending monitor can cycle between set->NULL->set->NULL when we run into a suspend request. Previously, it did not cycle. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From weijun at openjdk.java.net Mon May 24 21:51:32 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 21:51:32 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs wrote: > Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on. Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-( ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 25 06:25:23 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 25 May 2021 06:25:23 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: References: Message-ID: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". Hao Tang has updated the pull request incrementally with one additional commit since the last revision: Fix compile errors on MacOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3656/files - new: https://git.openjdk.java.net/jdk/pull/3656/files/d76fd441..066083e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From rehn at openjdk.java.net Tue May 25 06:35:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:35:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:28:15 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/prims/jvmtiRawMonitor.cpp line 405: > >> 403: >> 404: guarantee(self == _owner, "invariant"); >> 405: guarantee(save == _recursions, "invariant"); > > Since you just restored the `_recursions` field on L402, why do > you need this guarantee() 2 code lines later? I left it since if we do changes here those two should be true even after any changes. I can remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 06:43:12 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:43:12 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 17:44:33 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 212: > >> 210: _thread->frame_anchor()->make_walkable(_thread); >> 211: OrderAccess::storestore(); >> 212: _thread->set_thread_state(_thread_in_native); > > Please add a comment to the `storestore()` call: > // Keep thread_state change and make_walkable() separate. Fixed > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 251: > >> 249: thread->frame_anchor()->make_walkable(thread); >> 250: OrderAccess::storestore(); >> 251: thread->set_thread_state(_thread_blocked); > > Please add a comment to the storestore() call: > // Keep thread_state change and make_walkable() separate. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 06:49:16 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 06:49:16 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 17:57:44 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Final fixes: last famous words > > src/hotspot/share/runtime/objectMonitor.cpp line 451: > >> 449: // We cleared the pending monitor info since we've just gotten past >> 450: // the enter-check-for-suspend dance and we now own the monitor free >> 451: // and clear, i.e., it is no longer pending. > > This comment explains why the set-pending-to-NULL code was here > (outside the loop). You moved the code, but now the comment is > misplaced and the code no longer works the same. > > Update: I found this resolved comment below: > > And I set current->set_current_pending_monitor(om); to OM again > in ExitOnSuspend if we exit the OM. > > so that explains why we don't have a big change in behavior. > > However, I think you still need to do something about this comment. > > There is still an observable change in behavior in that the current > pending monitor can cycle between set->NULL->set->NULL when > we run into a suspend request. Previously, it did not cycle. If we stop for a suspend request current pending monitor will always be set, so the cycling cannot be seen. Updated comment(s). ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 07:06:58 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 07:06:58 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Fixes for Dan - Merge branch 'master' into 8265753 - Final fixes: last famous words - Review fixes 2 - Merge branch 'master' into 8265753 - Review fixes - Merge branch 'master' into 8265753 - Fixes for Dan - Merge branch 'master' into 8265753 - Removed manual transitions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3875/files - new: https://git.openjdk.java.net/jdk/pull/3875/files/cc15431e..30d62e85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3875&range=05-06 Stats: 9596 lines in 1190 files changed: 4469 ins; 2824 del; 2303 mod Patch: https://git.openjdk.java.net/jdk/pull/3875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3875/head:pull/3875 PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 07:12:08 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 07:12:08 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v6] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 18:12:00 GMT, Daniel D. Daugherty wrote: > Thumbs up. > > I just have some minor questions about a couple of the details. > Nothing blocking. Thanks Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From sgehwolf at openjdk.java.net Tue May 25 09:56:00 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 25 May 2021 09:56:00 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> References: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> Message-ID: On Tue, 25 May 2021 06:25:23 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with one additional commit since the last revision: > > Fix compile errors on MacOS Bumping number of required reviewers to 2 as I'm a contributing author of the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 25 11:42:21 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 25 May 2021 11:42:21 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v5] In-Reply-To: References: Message-ID: <2L47jsQSBzF9uwmdBG-_DVGjA5PNNKy1tCBbXrepXys=.d606890e-c4ea-4452-bd59-a503c22fc076@github.com> > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". Hao Tang has updated the pull request incrementally with one additional commit since the last revision: remove PER_CPU_SHARES ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3656/files - new: https://git.openjdk.java.net/jdk/pull/3656/files/066083e9..c7abec03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Tue May 25 11:42:42 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 25 May 2021 11:42:42 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> References: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> Message-ID: On Tue, 25 May 2021 06:25:23 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with one additional commit since the last revision: > > Fix compile errors on MacOS LGTM. Nit: Please remove `PER_CPU_SHARES` constant as it's no longer used. src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 44: > 42: > 43: private static final int MAX_ATTEMPTS_NUMBER = 10; > 44: private static final int PER_CPU_SHARES = 1024; I think this is no longer used anywhere so can get removed. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3656 From rrich at openjdk.java.net Tue May 25 13:08:06 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 25 May 2021 13:08:06 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Still looks good to me. Cheer's, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Tue May 25 13:38:03 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 25 May 2021 13:38:03 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: <375JabqE79ZBg7y-VsUTkHoex6Bou-NKSJyZvcfR-mY=.3e38489a-0e46-4828-92e2-2451508f0a63@github.com> On Tue, 25 May 2021 13:04:46 GMT, Richard Reingruber wrote: > Still looks good to me. > > Cheer's, Richard. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From mullan at openjdk.java.net Tue May 25 13:51:01 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 25 May 2021 13:51:01 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security In-Reply-To: References: Message-ID: On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang wrote: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709: > 707: } > 708: if (GSSUtil.useSubjectCredsOnly(caller)) { > 709: @SuppressWarnings("removal") It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above. ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From weijun at openjdk.java.net Tue May 25 16:20:35 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 25 May 2021 16:20:35 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: one more change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4172/files - new: https://git.openjdk.java.net/jdk/pull/4172/files/b22fd7d7..176f44e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172 PR: https://git.openjdk.java.net/jdk/pull/4172 From weijun at openjdk.java.net Tue May 25 16:20:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 25 May 2021 16:20:38 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 13:44:30 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> one more change > > src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709: > >> 707: } >> 708: if (GSSUtil.useSubjectCredsOnly(caller)) { >> 709: @SuppressWarnings("removal") > > It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above. Oops. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From sspitsyn at openjdk.java.net Tue May 25 20:17:35 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 25 May 2021 20:17:35 GMT Subject: RFR: 8263635: Add --servername option to jhsdb debugd [v5] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 01:45:59 GMT, Yasumasa Suenaga wrote: >> `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. >> >> As a result, remote name will be constructed as following: >> >> >> //host[:port]/['_'] >> >> >> However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. >> >> serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. >> And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. >> >> I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. >> This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Hi Yasumasa, It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3669 From mullan at openjdk.java.net Tue May 25 21:28:35 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 25 May 2021 21:28:35 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com> On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang wrote: >> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > one more change Update copyright dates to 2021, if applicable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From weijun at openjdk.java.net Tue May 25 21:38:38 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 25 May 2021 21:38:38 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com> References: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com> Message-ID: On Tue, 25 May 2021 21:25:54 GMT, Sean Mullan wrote: > Update copyright dates to 2021, if applicable. Will do. Since this PR can only be integrated after its parent PR #4073 is integrated. I'll delay the copyright update by then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From cjplummer at openjdk.java.net Tue May 25 21:43:21 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 25 May 2021 21:43:21 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. @AntonKozlov I thought there was recently a thread were you discussed this, but I can't find it. If there was one, can you include a link? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 25 21:46:51 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 25 May 2021 21:46:51 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: References: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> Message-ID: <1jNGqnPyx5PErHwQYny5mkEtPAXyIsiBAty34hIWGpM=.6254f320-a65b-4ea1-b590-d14f97f45f55@github.com> On Tue, 25 May 2021 09:53:02 GMT, Severin Gehwolf wrote: >> Hao Tang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compile errors on MacOS > > Bumping number of required reviewers to 2 as I'm a contributing author of the change. @jerboaa Thank you for the cpu-shares-based load calculation! I also update the cpu-quota-based load calculation to use the same strategy as the cpu-shares-based one, because my previous implementation always reports the average load since the container starts. Another change is to set the initial value of `usageTicks`/`totalTicks` to zero. Therefore, the first call of `getCpuLoad` can also report a reasonable result. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From github.com+7947546+tanghaoth90 at openjdk.java.net Tue May 25 21:46:27 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Tue, 25 May 2021 21:46:27 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". Hao Tang has updated the pull request incrementally with two additional commits since the last revision: - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation - rename usageTicks and totalTicks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3656/files - new: https://git.openjdk.java.net/jdk/pull/3656/files/c7abec03..eba3bc10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3656&range=04-05 Stats: 81 lines in 1 file changed: 32 ins; 39 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3656/head:pull/3656 PR: https://git.openjdk.java.net/jdk/pull/3656 From mullan at openjdk.java.net Tue May 25 21:53:04 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 25 May 2021 21:53:04 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang wrote: >> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > one more change Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From sspitsyn at openjdk.java.net Tue May 25 22:39:15 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 25 May 2021 22:39:15 GMT Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. Hi Albert, Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4146 From serguei.spitsyn at oracle.com Tue May 25 22:42:36 2021 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Tue, 25 May 2021 22:42:36 +0000 Subject: [8u] RFR: 8267426 MonitorVmStartTerminate test timed out on Embedded VM In-Reply-To: References: <93CA796B-702B-4078-88F6-0E74B9F5D181@azul.com> <19732680-A7C4-41CA-87C9-02CA29BDEB92@azul.com> Message-ID: <373AE15B-B432-4812-BCBF-048C90B92066@oracle.com> Hi Sergey, It looks good to me too (if you need one more review). Thanks, Serguei ?On 5/20/21, 6:36 AM, "jdk8u-dev on behalf of David Holmes" wrote: On 20/05/2021 8:27 pm, Sergey Nazarkin wrote: > Thanks David, I?ve tagged the bug > > The test is not new, I tracked it down to jdk7. But EmbeddedVM build is quite tricky and it seems nobody care about it nowadays. Looks like the test got a major overhaul after JDK 8 was released. That may be when it stopped working with SE Embedded. Or it may be we used to run the tests such that -XX:+UsePerfData was passed by jtreg ... I don't recall now. :) Cheers, David > > /Sergey > >> On May 20, 2021, at 03:50, David Holmes wrote: >> >> Hi Sergey, >> >> Fix looks fine. I'm a little surprised we have any SE Embedded test issues arising - is this a new test? >> >> Cheers, >> David >> >> >> On 20/05/2021 6:28 am, Sergey Nazarkin wrote: >>> Correct serviceability list address >>>> On May 19, 2021, at 22:19, Sergey Nazarkin wrote: >>>> >>>> Hi! >>>> >>>> Please review small patch for the test that fails [1] on jdk8 built with JAVASE_EMBEDDED option. >>>> >>>> Embedded VM build disables [2] jvmstat instrumentation that prevent launched instance be detected by test agent. The fix [3] enables instrumentation for launched VM swarm and agent is able to detect them. >>>> >>>> The bug affects jdk8 only [4]. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8267426 >>>> [2] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/file/8c40ddd927ce/src/share/vm/runtime/globals.hpp#l3782 >>>> [3] http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8267426/ >>>> [4] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/bce3c3659531/src/hotspot/share/runtime/globals.hpp#l2413 >>>> >>>> >>>> >>>> > From dholmes at openjdk.java.net Tue May 25 23:03:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:03:28 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Nothing further from me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From dholmes at openjdk.java.net Tue May 25 23:06:14 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 25 May 2021 23:06:14 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update HotSpot style guide documents doc/hotspot-style.html line 97: > 95:
  • Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.

  • > 96:
  • .inline.hpp files should only be included in .cpp or .inline.hpp files.

  • > 97:
  • All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.

  • typo: the the Need space after between on last line ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From github.com+7947546+tanghaoth90 at openjdk.java.net Wed May 26 01:55:14 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Wed, 26 May 2021 01:55:14 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: References: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> Message-ID: On Tue, 25 May 2021 09:56:50 GMT, Severin Gehwolf wrote: >> Hao Tang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compile errors on MacOS > > src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 44: > >> 42: >> 43: private static final int MAX_ATTEMPTS_NUMBER = 10; >> 44: private static final int PER_CPU_SHARES = 1024; > > I think this is no longer used anywhere so can get removed. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From dholmes at openjdk.java.net Wed May 26 02:21:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 02:21:11 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 12:58:45 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update HotSpot style guide documents Hi Stefan, I think this policy makes a lot of sense! I only scanned through the changes to get a sense of them but it all seemed fine. Thanks, David doc/hotspot-style.md line 142: > 140: > 141: * All .inline.hpp files should include their corresponding .hpp file > 142: as the first include line. Externally used declarations should be put Do we need to spell out it should be first unless precompiled.hpp is included? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4127 From github.com+7947546+tanghaoth90 at openjdk.java.net Wed May 26 06:24:15 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Wed, 26 May 2021 06:24:15 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com> References: <_0A4T59iEBewRm5dMoroZ9fO5vN6KelqcHZavcALIm4=.8249eddd-fc07-4443-816e-5178a9f3a90b@github.com> Message-ID: On Fri, 21 May 2021 16:11:49 GMT, Severin Gehwolf wrote: >>> @tanghaoth90 My local testing suggests that your fix addresses the issue of CPU quotas set via `--cpu-quota/--cpu-period`. When using `--cpu-shares` the CPU load calculation is wrong since it will (wrongly) report host values. Lets look at them individually, fix the quota and shares case individually (i.e. when not both are set). Once that's done, quota will be preferred in the OperatingSystemMXBean impl, which is reasonable. I don't think we need to account for the shares-preferred-over-quota at this point since that changed in HotSpot in JDK 11 time-frame (JDK-8197589) and OperatingSystemMXBean has only been made container aware in JDK 14 (yes, it got backported, but still). >> >> @jerboaa I have updated my fix by inserting a new branch for `--cpu-shares`. By setting up containers with different restrictions based on your suggestion, I noticed two problems for the CPU load calculation. Take [TestLoad.java](https://bugs.openjdk.java.net/secure/attachment/94530/TestLoad.java) as the example. >> >> 1. `--cpu-quota=700000 --cpu-period=100000` as the restriction: the result is getting close to `6/7` slowly as time goes by, which indicates that the result of >> >> long usageNanos = containerMetrics.getCpuUsage(); >> >> is an accumulated CPU usage rather than a real-time CPU usage. >> According to the javadoc, `getCpuLoad()` _returns the "recent cpu usage"_. The current fix obviously does not address this issue. >> >> 2. `--cpu-shares=2048` as the restriction: the "cpu-share" branch only returns `-1` since `containerMetrics.getCpuNumPeriods()` returns `0` (`nr_periods` of `cpu.stat` stays `0` when only `--cpu-shares` is set). By now, I have no idea to compute the elapsed time or the total available CPU time with the help of the methods of `jdk.internal.platform.CgroupMetrics`. >> >> Any suggestion is appreciated. @jerboaa @argha-c > > @tanghaoth90 > > As to your observation of 1). Yes, that's true and I'm not sure it's worth changing. We could change the javadoc. > > As for 2) I've created a PR for your branch with a suggested implementation for cpu shares based accounting. It uses a similar heuristics than the getCpuLoad0() uses here: > https://github.com/openjdk/jdk/blob/master/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L278 > > That's the best I could think of. It's certainly more accurate than the current implementation. @jerboaa Just read your comment about my observation (due to the weird format of github pull request). Sorry for making further [change](https://github.com/openjdk/jdk/pull/3656/commits/eba3bc10b4ebd) for the `quota` branch without asking for your suggestion. For now, I still hold a different opinion about the `quota` branch. My local test shows that podman run --cpu-shares=4096 podman run --cpu-quota=400000 --cpu-period=100000 yields the same result after the change, otherwise the second one still prints the average cpu load. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From rehn at openjdk.java.net Wed May 26 06:24:23 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 26 May 2021 06:24:23 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 22:59:55 GMT, David Holmes wrote: > Nothing further from me. > > Thanks, > David Thank you David! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From stefank at openjdk.java.net Wed May 26 06:38:47 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 26 May 2021 06:38:47 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5] In-Reply-To: References: Message-ID: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review dholmes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4127/files - new: https://git.openjdk.java.net/jdk/pull/4127/files/ba9ad1b1..0cf6257d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From stefank at openjdk.java.net Wed May 26 06:38:53 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 26 May 2021 06:38:53 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 02:18:06 GMT, David Holmes wrote: > Hi Stefan, > > I think this policy makes a lot of sense! > > I only scanned through the changes to get a sense of them but it all seemed fine. > > Thanks, > David Thanks a lot for reviewing! > doc/hotspot-style.html line 97: > >> 95:
  • Do not put non-trivial function implementations in .hpp files. If the implementation depends on other .hpp files, put it in a .cpp or a .inline.hpp file.

  • >> 96:
  • .inline.hpp files should only be included in .cpp or .inline.hpp files.

  • >> 97:
  • All .inline.hpp files should include their corresponding .hpp file as the first include line. Externally used declarations should be put in the .hpp file, and not in the the .inline.hpp file. This rule exists to resolve problems with circular dependencies between.inline.hpp files.

  • > > typo: the the > Need space after between on last line Fixed. > doc/hotspot-style.md line 142: > >> 140: >> 141: * All .inline.hpp files should include their corresponding .hpp file >> 142: as the first include line. Externally used declarations should be put > > Do we need to spell out it should be first unless precompiled.hpp is included? We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that. ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From ayang at openjdk.java.net Wed May 26 06:53:17 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 26 May 2021 06:53:17 GMT Subject: RFR: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer In-Reply-To: References: Message-ID: <4yHlfwn57DzEGk0FzmvZpC-x5811b8e0gvTaeeEw-5w=.340ae43e-9293-4623-8c1e-d1de77eb41bd@github.com> On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4146 From ayang at openjdk.java.net Wed May 26 06:53:17 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 26 May 2021 06:53:17 GMT Subject: Integrated: 8267468: Rename refill waster counters in ThreadLocalAllocBuffer In-Reply-To: References: Message-ID: On Fri, 21 May 2021 14:15:11 GMT, Albert Mingkun Yang wrote: > Followup of https://bugs.openjdk.java.net/browse/JDK-8234532 (https://github.com/openjdk/jdk/pull/3756), dropping the "slow" segment in various counter names. This pull request has now been integrated. Changeset: 03944168 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/039441689d21f3dccf515bb2be89608b0772a235 Stats: 45 lines in 4 files changed: 2 ins; 0 del; 43 mod 8267468: Rename refill waster counters in ThreadLocalAllocBuffer Reviewed-by: kbarrett, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/4146 From dholmes at openjdk.java.net Wed May 26 07:56:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 26 May 2021 07:56:13 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v4] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 06:35:29 GMT, Stefan Karlsson wrote: >> doc/hotspot-style.md line 142: >> >>> 140: >>> 141: * All .inline.hpp files should include their corresponding .hpp file >>> 142: as the first include line. Externally used declarations should be put >> >> Do we need to spell out it should be first unless precompiled.hpp is included? > > We should never include precompiled.hpp from an .inline.hpp file, so I don't think we need to state that. Ah. Right. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From sgehwolf at openjdk.java.net Wed May 26 08:06:15 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 26 May 2021 08:06:15 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v4] In-Reply-To: References: <8LCPn2zXP9ja5Ru-xdEafV94W62yTrBF5KwVPJONrKg=.6c5b8779-fc63-4e01-bd56-ae0e0d243cf5@github.com> Message-ID: <8j5D125IbrWFmQ30WHFHau1e3Uv7fzMA7eOjywr5lxU=.aed0925b-5220-4300-b99e-d0c0c282a379@github.com> On Tue, 25 May 2021 09:53:02 GMT, Severin Gehwolf wrote: >> Hao Tang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compile errors on MacOS > > Bumping number of required reviewers to 2 as I'm a contributing author of the change. > @jerboaa Thank you for the cpu-shares-based load calculation! I also update the cpu-quota-based load calculation to use the same strategy as the cpu-shares-based one, because my previous implementation always reports the average load since the container starts. OK. > Another change is to set the initial value of `usageTicks`/`totalTicks` to zero. Therefore, the first call of `getCpuLoad` can also report a reasonable result. Seems reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Wed May 26 08:06:15 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 26 May 2021 08:06:15 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:46:27 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with two additional commits since the last revision: > > - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation > - rename usageTicks and totalTicks Still good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at redhat.com Wed May 26 08:30:26 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 May 2021 10:30:26 +0200 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com> References: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com> <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com> Message-ID: <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com> On Mon, 2021-05-03 at 17:57 -0700, Laurence Cable wrote: > > On 5/3/21 4:50 PM, David Holmes wrote: > > On 4/05/2021 9:07 am, Argha C wrote: > > > Hello David, > > > It does look quite similar. > > > The crux is factoring in the sum of cpu time across all?shares, > > > instead of a single cpu share. > > > My proposal for implementing the fix is slightly different from > > > the PR, but happy to trust your advice on taking this forward. > > > > I would suggest liaising with the contributors of > > > > https://github.com/openjdk/jdk/pull/3656 > > > > so see if all of the issues can be addressed together. > > +1! David, Larry: https://github.com/openjdk/jdk/pull/3656 ... is ready for integration. Could we get a second review, please? It addresses wrong cpuLoad() calculation of cpu quota and cpu shares-based cpu limits in containers. Thoughts? Thanks, Severin From david.holmes at oracle.com Wed May 26 08:45:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 May 2021 18:45:34 +1000 Subject: OperatingSystemImpl should factor cpu shares when calculating system load In-Reply-To: <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com> References: <5920b792-e83c-1728-ae35-a229797b59f4@oracle.com> <6da4ac22-b109-6470-1145-a878cb6d235d@oracle.com> <5aba1620-d10c-6586-8c3d-673ac58f6c4c@oracle.com> <7b47298b5c53ff94e52d781f90deee9b570dfe1d.camel@redhat.com> Message-ID: Hi Severin, On 26/05/2021 6:30 pm, Severin Gehwolf wrote: > On Mon, 2021-05-03 at 17:57 -0700, Laurence Cable wrote: >> >> On 5/3/21 4:50 PM, David Holmes wrote: >>> On 4/05/2021 9:07 am, Argha C wrote: >>>> Hello David, >>>> It does look quite similar. >>>> The crux is factoring in the sum of cpu time across all?shares, >>>> instead of a single cpu share. >>>> My proposal for implementing the fix is slightly different from >>>> the PR, but happy to trust your advice on taking this forward. >>> >>> I would suggest liaising with the contributors of >>> >>> https://github.com/openjdk/jdk/pull/3656 >>> >>> so see if all of the issues can be addressed together. >> >> +1! > > David, Larry: > > https://github.com/openjdk/jdk/pull/3656 > > ... is ready for integration. Could we get a second review, please? It > addresses wrong cpuLoad() calculation of cpu quota and cpu shares-based > cpu limits in containers. > > Thoughts? Sorry, although I connected the two bugs reports I'm not familiar enough with this area to review anything. I don't work with containers and don't understand their resource management strategies or how the VM should report them. David ----- > Thanks, > Severin > From akozlov at openjdk.java.net Wed May 26 09:37:13 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 26 May 2021 09:37:13 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance. I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From kbarrett at openjdk.java.net Wed May 26 14:38:15 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 26 May 2021 14:38:15 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 06:38:47 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review dholmes doc/hotspot-style.md line 142: > 140: > 141: * All .inline.hpp files should include their corresponding .hpp file > 142: as the first include line. Externally used declarations should be put I think by "Externally used declarations" you mean "declarations needed by other headers"? Maybe say it that way, or some other wording? ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From dcubed at openjdk.java.net Wed May 26 14:48:24 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 26 May 2021 14:48:24 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Thumbs up. Reviewed the incremental between v05 -> v06. Looks good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Wed May 26 15:21:22 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 15:21:22 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 07:43:06 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 277: >> >>> 275: class ThreadBlockInVM { >>> 276: InFlightMutexRelease _ifmr; >>> 277: ThreadBlockInVMPreprocess _tbivmpp; >> >> Why delegate to the TBIVMPP instead of extending it? > > I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From coleenp at openjdk.java.net Wed May 26 17:15:14 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 26 May 2021 17:15:14 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis wrote: > In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. > > This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. > > In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. > > The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). > > I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: > > // Copy the "source file name" attribute from new class version > the_class->set_source_file_name_index( > scratch_class->source_file_name_index()); > > Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? I'm sorry for the delay and for introducing the bug. I'm hopefully back in the frame of mind I was in when making the change. See if what I said makes sense. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861: > 1859: // Save fields from the old_cp. > 1860: merge_cp->copy_fields(old_cp(), true /* skip_version */); > 1861: scratch_cp->copy_fields(old_cp(), true /* skip_version */); Rather than calling copy_fields, maybe this should revert this: - if (old_cp->has_dynamic_constant()) { - merge_cp->set_has_dynamic_constant(); - scratch_cp->set_has_dynamic_constant(); - } And then the merge_cp->copy_fields(scratch_cp); ? The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class(). src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4412: > 4410: the_class->constants()->set_major_version(scratch_class->constants()->major_version()); > 4411: scratch_class->constants()->set_major_version(old_major_version); > 4412: This looks correct. copy_fields doesn't swap the versions, and I think that's what we want to do. The source_name_index should match the scratch_class which is above, and the generic_signature_index is checked that it matches, and the one in the scratch constant pool should be adjusted to match the merged constant pool. So I think that's ok. test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1: > 1: /* Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory? All the tests do redefinition differently. There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent. @ compile TestClassXXX.jasm // this is the old one then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use RedefineClassHelper.redefine(TestClassXXX.class, newBytes); See RedefineRunningMethods.java in that directory for an example. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4149 From stefank at openjdk.java.net Wed May 26 18:00:54 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 26 May 2021 18:00:54 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6] In-Reply-To: References: Message-ID: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com> > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review kbarrett ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4127/files - new: https://git.openjdk.java.net/jdk/pull/4127/files/0cf6257d..340bcf49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From sgehwolf at openjdk.java.net Wed May 26 18:03:16 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 26 May 2021 18:03:16 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: <1cIXMnCe0NR1K4A3AXD9NhV7SpirI6caIXLt3LSJXNk=.0a5ffbf8-c159-4db1-923f-cc9314e5bfa9@github.com> On Tue, 25 May 2021 21:46:27 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with two additional commits since the last revision: > > - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation > - rename usageTicks and totalTicks Any other reviewers, please? @YaSuenag perhaps? ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From rehn at openjdk.java.net Wed May 26 18:35:33 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 26 May 2021 18:35:33 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 15:18:43 GMT, Patricio Chilano Mateo wrote: >> I need to run the InFlightMutexRelease constructor before I can run the ThreadBlockInVMPreprocess constructor. > > Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? You mean revert your change of having the monitor as a parameter to ThreadBlockInVM? And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM? I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :) So I can open an RFE if you want? ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Wed May 26 18:50:51 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 18:50:51 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 07:06:58 GMT, Robbin Ehn wrote: >> Please consider this change which removes the manual transitions to blocked. >> This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. >> This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. >> >> The object monitor code could be straight forward changed to use this instead of manual transitions. >> >> Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). >> Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. >> This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. >> Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. >> That made it possible to careful use ThreadInVMfromNative in raw monitors. >> >> I also remove the early CAS in raw_enter. >> We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. >> Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. >> (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) >> >> Passes t1-t7 and manual stressing relevant test groups. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Final fixes: last famous words > - Review fixes 2 > - Merge branch 'master' into 8265753 > - Review fixes > - Merge branch 'master' into 8265753 > - Fixes for Dan > - Merge branch 'master' into 8265753 > - Removed manual transitions Marked as reviewed by pchilanomate (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From pchilanomate at openjdk.java.net Wed May 26 18:50:52 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 26 May 2021 18:50:52 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v3] In-Reply-To: References: Message-ID: <2EZdZ8P_QGnZuMmQtUdXmT2LhfY2p043OvLIARFjpb0=.0f89ec87-668d-46e0-bda0-cce14ddb2a37@github.com> On Wed, 26 May 2021 18:30:16 GMT, Robbin Ehn wrote: >> Just for consistency, shouldn't we just use ThreadBlockInVMPreprocess in mutex.cpp as we are using it in objectMonitor.cpp? > > You mean revert your change of having the monitor as a parameter to ThreadBlockInVM? > And instead just place InFlightMutexRelease in mutex and directly use ThreadBlockInVMPreprocess as OM? > I don't mind mind either way, but I feel changing two of three locking implementation is enough in one change-set :) > So I can open an RFE if you want? Right, so when we added the _in_flight_mutex_addr to TBIVM this was the only case where we would need to check a condition and execute some action, but now that we are doing it from objectMonitors and jvmtiRawMonitors too then it seems we should use it the same way here. Sure, we can do it in another RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From kbarrett at openjdk.java.net Wed May 26 23:06:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 26 May 2021 23:06:05 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6] In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com> References: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com> Message-ID: On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review kbarrett Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4127 From ysuenaga at openjdk.java.net Thu May 27 00:50:15 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 27 May 2021 00:50:15 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:46:27 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with two additional commits since the last revision: > > - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation > - rename usageTicks and totalTicks I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`. `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok? IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From ysuenaga at openjdk.java.net Thu May 27 04:57:08 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 27 May 2021 04:57:08 GMT Subject: Integrated: 8263635: Add --servername option to jhsdb debugd In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 03:15:07 GMT, Yasumasa Suenaga wrote: > `jhsdb debugd` supports server name prefix with `sun.jvm.hotspot.rmi.serverNamePrefix` system property. It will be used as remote name for SA RMI object. It is "SARemoteDebugger" by default. > > As a result, remote name will be constructed as following: > > > //host[:port]/['_'] > > > However we have no way to set it excepting system property. jhsdb should provide the way to set it as a command line option. > > serverNamePrefix is used for RMI object name, so "server name" is more suitable for it. Thus I will add `--servername` to `jhsdb debugd` for this purpose. > And also we should add the way to specify it when we connect to debug server. I will add it like `--connect id at server:1234/servername`. > > I've also filed [CSR for this PR](https://bugs.openjdk.java.net/browse/JDK-8265897). Please review it. > This PR modifies DisableRegistryTest.java, but it has been addressed in ProblemList-zgc.txt now. So this PR does not affect ZGC. This pull request has now been integrated. Changeset: 37bc4e2e Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/37bc4e2e3c2968d7419dae4f421755b6f7d06090 Stats: 153 lines in 12 files changed: 49 ins; 10 del; 94 mod 8263635: Add --servername option to jhsdb debugd Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3669 From ysuenaga at openjdk.java.net Thu May 27 05:03:04 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 27 May 2021 05:03:04 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 In-Reply-To: References: Message-ID: <0Se6sGcQIcQluyLcvnGv8A3a_6SBRCkUOskxbqdBSfU=.5a11da9b-94ae-4e26-af77-505722bdbd71@github.com> On Mon, 17 May 2021 12:07:13 GMT, Yasumasa Suenaga wrote: > Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). > > * serviceability/sa/ClhsdbDumpheap.java > * serviceability/sa/ClhsdbFindPC.java > * serviceability/sa/ClhsdbInspect.java > * serviceability/sa/ClhsdbSymbol.java > * serviceability/sa/TestHeapDumpForInvokeDynamic.java > * serviceability/sa/TestJmapCore.java > * serviceability/sa/TestJmapCoreMetaspace.java > > They need to handle relocated objects and/or live regions (pages). SA should handle them. > > This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help? Ping: could you review this change? I know this is too big to review, so it is also welcome to comment to divide this PR. This PR would fix [JDK-8267045](https://bugs.openjdk.java.net/browse/JDK-8267045) which is marked as P3. If we can mark P3 to this PR, we can get more time to review. I think SA should support ZGC as possible in next major release. ------------- PR: https://git.openjdk.java.net/jdk/pull/4057 From stefank at openjdk.java.net Thu May 27 07:15:06 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 27 May 2021 07:15:06 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v6] In-Reply-To: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com> References: <-N-g2LtXiLzyl-1Z_61StqnhLz01OMEaH1rrUFgHv5c=.10a88ce2-4a54-4fcd-a1a4-6b8083e8df1f@github.com> Message-ID: On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review kbarrett @vnkozlov Can we considered the proposed changes to HotSpot Coding Style sufficiently reviewed? ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From github.com+7947546+tanghaoth90 at openjdk.java.net Thu May 27 08:40:12 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Thu, 27 May 2021 08:40:12 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 00:47:23 GMT, Yasumasa Suenaga wrote: > `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok? > IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior. @YaSuenag Thanks for your comment. I can give two reasons for that. 1. The javadoc of `OperatingSystemMXBean.getCpuLoad` indicates the method should return "recent cpu usage". https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java#L156 2. The initial (container-unaware) implementation `getCpuLoad0` does reports recent CPU load, which the container-aware implementation must be consistent. > but after this PR, it is based on the ticks in earlier call. Is it ok? The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that? ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Thu May 27 08:56:07 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 27 May 2021 08:56:07 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: <7IXKfZfx7S4zHKfhgZRKoneDcqI1FQQm7-7Qgs68ACc=.fb51e01a-0310-4fe8-adc9-09db5a3d886a@github.com> On Thu, 27 May 2021 00:47:23 GMT, Yasumasa Suenaga wrote: > I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`. Does it? Here is the javadoc: https://docs.oracle.com/en/java/javase/16/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getCpuLoad() It says: Returns the "recent cpu usage" for the operating environment. This value is a double in the [0.0,1.0] interval. If I run outside a container, getCpuLoad0() is being used which uses a similar calculation. So in my book this fixes the bug (earlier reporting is just plain wrong, see bug for details) and just brings it in line with the non-container values. Also note that the cpu quota-based limits implementation as been changed to also report recent load values. But I'm not sure it's worth discussing this further as the previous implementation (supposedly reporting an average) was wrong. > `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok? IMHO, yes as the previous implementation was incorrect. I suspect nobody noticed until now. > IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior. I disagree. This change makes `getCpuLoad()` behave similar in all cases: non-container case[1], cpu affinity-based[2], cpu-quota-based[3] and cpu-shares based[3] cpu-limits. That wasn't previously the case. [1] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423632&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423632 [2] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423633&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423633 [3] https://bugs.openjdk.java.net/browse/JDK-8265836?focusedCommentId=14423371&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14423371 ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From ysuenaga at openjdk.java.net Thu May 27 09:22:09 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 27 May 2021 09:22:09 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 21:46:27 GMT, Hao Tang wrote: >> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. >> >> We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). >> "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". > > Hao Tang has updated the pull request incrementally with two additional commits since the last revision: > > - Use historical-value-based formula for both cpu-quota-based and cpu-shares-based calculation > - rename usageTicks and totalTicks @tanghaoth90 @jerboaa Thank you for explanation! > The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that? I concerned about that too. Javadoc says "recent cpu usage" about this - it is ambiguous. In other words, our concerns are tolerated IMHO. Of course it is better if we can get sampling value, but it is difficult now. Maybe we can implement sampling thread, but we need to think some things (e.g. sampling frequency). I'm not sure it is worth to work for it. I think it is important that `getCpuLoad()` behaves similar in all cases, and also I can't see any problems in your change. So I give +1 to your change ?? ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3656 From sgehwolf at openjdk.java.net Thu May 27 09:37:08 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 27 May 2021 09:37:08 GMT Subject: RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container [v6] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 08:37:11 GMT, Hao Tang wrote: >> I haven't followed yet all of discussions in this review, but I concern this PR changes the meaning of `getCpuLoad()`. >> >> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok? >> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior. > >> `getCpuLoad()` has been based on total time since the start of the container, but after this PR, it is based on the ticks in earlier call. Is it ok? >> IMHO it can be accepted because it is the same with load average on Linux, but I concern we may need CSR because this PR changes behavior. > > @YaSuenag Thanks for your comment. I can give two reasons for that. > 1. The javadoc of `OperatingSystemMXBean.getCpuLoad` indicates the method should return "recent cpu usage". > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java#L156 > 2. The initial (container-unaware) implementation `getCpuLoad0` does reports recent CPU load, which the container-aware implementation must be consistent. > >> but after this PR, it is based on the ticks in earlier call. Is it ok? > > The result might be too coarse/inaccurate, if the time between two calls is too long/short. Any comments for that? > @tanghaoth90 @jerboaa Thank you for explanation! Thanks very much for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From simonis at openjdk.java.net Thu May 27 10:26:46 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 27 May 2021 10:26:46 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 [v2] In-Reply-To: References: Message-ID: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> > In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. > > This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. > > In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. > > The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). > > I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: > > // Copy the "source file name" attribute from new class version > the_class->set_source_file_name_index( > scratch_class->source_file_name_index()); > > Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: 8267555: Fix class file version during redefinition after 8238048 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4149/files - new: https://git.openjdk.java.net/jdk/pull/4149/files/25f07246..45d6d006 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4149&range=00-01 Stats: 262 lines in 7 files changed: 102 ins; 150 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4149.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4149/head:pull/4149 PR: https://git.openjdk.java.net/jdk/pull/4149 From simonis at openjdk.java.net Thu May 27 10:26:48 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 27 May 2021 10:26:48 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis wrote: > In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. > > This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. > > In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. > > The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). > > I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: > > // Copy the "source file name" attribute from new class version > the_class->set_source_file_name_index( > scratch_class->source_file_name_index()); > > Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? Hi Coleen, thanks for reviewing my change. I've updated the code as suggested and moved the test to the new location. Thanks for pointing me to `RedefineClassHelper`. That considerably simplifies the test. Please let me know what you think? Best regards, Volker ------------- PR: https://git.openjdk.java.net/jdk/pull/4149 From simonis at openjdk.java.net Thu May 27 10:26:52 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 27 May 2021 10:26:52 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 [v2] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 16:42:20 GMT, Coleen Phillimore wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267555: Fix class file version during redefinition after 8238048 > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1861: > >> 1859: // Save fields from the old_cp. >> 1860: merge_cp->copy_fields(old_cp(), true /* skip_version */); >> 1861: scratch_cp->copy_fields(old_cp(), true /* skip_version */); > > Rather than calling copy_fields, maybe this should revert this: > - if (old_cp->has_dynamic_constant()) { > - merge_cp->set_has_dynamic_constant(); > - scratch_cp->set_has_dynamic_constant(); > - } > > And then the merge_cp->copy_fields(scratch_cp); ? > > The merged_cp should look like the scratch_cp (with version number and generic signature, etc) until after verification and then I guess it should look like the old_cp at the end in redefine_single_class(). Yes, that works as well. Updated as suggested. > test/hotspot/jtreg/runtime/ConstantPool/ClassVersion/ClassVersionAfterRedefine.java line 1: > >> 1: /* > > Can you put this test in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses directory? > All the tests do redefinition differently. There is a library RedefineClassHelper that you might be able to use and not have to deal with starting the agent. > > @ compile TestClassXXX.jasm // this is the old one > then in the test read all of TestClassNew.jasm bytecodes, and s/New/XXX/ and use > RedefineClassHelper.redefine(TestClassXXX.class, newBytes); > > See RedefineRunningMethods.java in that directory for an example. Moved the test to `test/hotspot/jtreg/serviceability/jvmti/RedefineClasses` and use `RedefineClassHelper` as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/4149 From coleenp at openjdk.java.net Thu May 27 13:21:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 27 May 2021 13:21:08 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 [v2] In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> References: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> Message-ID: On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis wrote: >> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. >> >> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. >> >> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. >> >> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). >> >> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: >> >> // Copy the "source file name" attribute from new class version >> the_class->set_source_file_name_index( >> scratch_class->source_file_name_index()); >> >> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > 8267555: Fix class file version during redefinition after 8238048 Yes, this looks good. Isn't RedefineClassHelper great? Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4149 From lzang at openjdk.java.net Thu May 27 14:00:03 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 27 May 2021 14:00:03 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> On Wed, 26 May 2021 09:34:06 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > AFAIK such enhancement was not discussed before. Please consider this review request also as a start of a discussion. The implementation is rather small, so I thought it was not worth a separate CFD in advance. > > I added few details to the bug. The change does not depend on a particular operating system, but on Linux, for example, the new option allows sending the dump to the external LZ4 process. It provides a compressed dump of the heap 2x faster than it is possible now, at the speed comparable to writing uncompressed dump. > > Thanks! Hi @AntonKozlov, I am not a reviewer, just a tiny hint that you may need to add test cases. Thanks, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From lzang at openjdk.java.net Thu May 27 14:04:07 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 27 May 2021 14:04:07 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: References: Message-ID: <_Q4Udr3OeDaLPcDEuGfcUXCW1WNx_tCQCO3u3iMWPIU=.0cd90173-a8b5-43ef-b11f-6a6cc1d52517@github.com> On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Moreover, it seems the /csr label is required ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From github.com+7947546+tanghaoth90 at openjdk.java.net Thu May 27 14:44:13 2021 From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang) Date: Thu, 27 May 2021 14:44:13 GMT Subject: Integrated: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 13:33:42 GMT, Hao Tang wrote: > OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though the CPU load is obviously below 100%. > > We created a 5-core container and run 4 "while (true)" loops in the container. OperatingSystemImpl.getCpuLoad() returned 1.0, which is incorrect (0.8 is correct). > "systemLoad" in getCpuLoad() is exactly 4.0 before "systemLoad = Math.min(1.0, systemLoad);". The problem is caused by using the elapsed time (specified by "cpu.cfs_period_us") instead of the total CPU time (specified by "cpu.cfs_quota_us"). Therefore, it is more reasonable to divide cpu usage time by "quotaNanos" instead of "elapsedNanos". This pull request has now been integrated. Changeset: ef368b32 Author: Hao Tang Committer: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/ef368b32bc8609bdc46cda628fa25e9bcad751e3 Stats: 90 lines in 4 files changed: 78 ins; 2 del; 10 mod 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container Co-authored-by: Shaojun Wang Co-authored-by: Severin Gehwolf Reviewed-by: sgehwolf, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/3656 From mdoerr at openjdk.java.net Thu May 27 15:53:05 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 15:53:05 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson wrote: > I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192. Hi Stefan, thanks for looking at it and thanks for the pointer. I do remember that Atomic::load should be preferred. But I would have to use it in thread.hpp and I don't know if I should change it in current_waiting_monitor() and current_pending_monitor(). Would it be acceptable to change the general code for this special usage? I'm not against doing it, I just want to double-check. It may improve reliability in general. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Thu May 27 16:47:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 27 May 2021 16:47:07 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Thumbs up. The code that you're fixing is indeed a special case and I wrote the new test (serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java) specifically to stress the crashing code path. Unfortunately, I have never seen the new test fail in our test in Mach5 or in my testing in my lab. We did get a single closed test failure back on 2021.03.20 which is what started me down the path of creating the new test. That single failure has never reproduced in the original closed test nor in the targeted test that I wrote (GetLockOwnerName.java). The similar usage in JVM/TI is safe for exactly the reasons explained in the comment so a general Atomic::load() solution in current_waiting_monitor() or current_pending_monitor() is not necessary. I think your solution of adding `volatile` to `wait_obj` and `enter_obj` is a good solution. I would like to see a comment added to explain the need for the `volatile`. I'll add an embedded comment in the other PR view. Using either `wait_obj` or `enter_obj` after it has been cleared from the JavaThread is safe. The ObjectMonitor can only have gone through the first stage of async deflation. The ObjectMonitor's memory cannot be freed until after a handshake with all threads is completed and that cannot happen while this thread is executing the code that is using `wait_obj` or `enter_obj`. src/hotspot/share/services/threadService.cpp line 232: > 230: // ObjectMonitor by the time this object reference is processed > 231: // by the caller. > 232: ObjectMonitor* volatile wait_obj = thread->current_waiting_monitor(); Please add a comment above this declaration. Something like: // Using 'volatile' to prevent the compiler from generating code that // reloads 'wait_obj' from memory when used below. src/hotspot/share/services/threadService.cpp line 239: > 237: obj = wait_obj->object(); > 238: } else { > 239: ObjectMonitor* volatile enter_obj = thread->current_pending_monitor(); Please add a comment above this declaration. Something like: // Using 'volatile' to prevent the compiler from generating code that // reloads 'enter_obj' from memory when used below. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 16:56:25 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 16:56:25 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Add comments as suggested by Dan. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/6e444fab..97a7df60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Thu May 27 17:01:12 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 27 May 2021 17:01:12 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments as suggested by Dan. Thanks for the review! Comment added. We have only seen the crash on s390. It depends on the platform if the compiler tends to reload values more or less. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From prr at openjdk.java.net Thu May 27 17:15:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 27 May 2021 17:15:06 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > keep only one systemProperty tag Marked as reviewed by prr (Reviewer). I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138 ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 27 17:46:07 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 27 May 2021 17:46:07 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java src/java.desktop/share/classes/java/awt/Component.java line 630: > 628: } > 629: > 630: @SuppressWarnings("removal") I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring that was needed because of the usage in this static block and you could not apply the annotation here. Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. Can you explain ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Thu May 27 20:16:25 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 27 May 2021 20:16:25 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04 Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From lmesnik at openjdk.java.net Thu May 27 20:20:22 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 27 May 2021 20:20:22 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Message-ID: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace ------------- Commit messages: - space removed. - 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Changes: https://git.openjdk.java.net/jdk/pull/4217/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4217&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265148 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4217/head:pull/4217 PR: https://git.openjdk.java.net/jdk/pull/4217 From lmesnik at openjdk.java.net Thu May 27 20:20:22 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 27 May 2021 20:20:22 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace I verified that running sunflow with async-profiler crashed VM before the fix and finished successfully after the fix. I compared data for G1GC for older JDK before https://bugs.openjdk.java.net/browse/JDK-8253180 is implemented. The results look pretty similar. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From sspitsyn at openjdk.java.net Thu May 27 21:31:05 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 27 May 2021 21:31:05 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 [v2] In-Reply-To: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> References: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> Message-ID: On Thu, 27 May 2021 10:26:46 GMT, Volker Simonis wrote: >> In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. >> >> This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. >> >> In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. >> >> The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). >> >> I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: >> >> // Copy the "source file name" attribute from new class version >> the_class->set_source_file_name_index( >> scratch_class->source_file_name_index()); >> >> Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > 8267555: Fix class file version during redefinition after 8238048 Hi Volker, The fix looks okay to me. Thank you for fixing it! Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4149 From amenkov at openjdk.java.net Thu May 27 23:09:24 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 27 May 2021 23:09:24 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. Message-ID: nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). This makes possible failure when debuggee tries to connect before debugger starts listening. The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. Couple details about the fix: - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. Testing: all tests which use IOPipe/SocketIOPipe classes: - test/hotspot/jtreg/serviceability/dcmd/framework - test/hotspot/jtreg/vmTestbase/nsk/jdi - test/hotspot/jtreg/vmTestbase/nsk/jdwp ------------- Commit messages: - FIx for serviceability/dcmd/framework tests Changes: https://git.openjdk.java.net/jdk/pull/4235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8237388 Stats: 143 lines in 5 files changed: 74 ins; 51 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4235/head:pull/4235 PR: https://git.openjdk.java.net/jdk/pull/4235 From dholmes at openjdk.java.net Thu May 27 23:11:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 27 May 2021 23:11:06 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Hi Leonid, Someone familiar with Stackwatermarks will need to comment about the validity of doing this, my only comment is to document why it is being turned off. Thanks, David src/hotspot/share/prims/forte.cpp line 326: > 324: int loop_count; > 325: int loop_max = MaxJavaStackTraceDepth * 2; > 326: RegisterMap map(thread, false, false); Can we add some comments as to what the false parameters mean please. RegisterMap map(thread, false /* no update */, false /*no stackwatermark frame processing */); Though it may be that a more elaborate block comment is needed to explain why we don't want stackwatermark frame processing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From weijun at openjdk.java.net Fri May 28 02:01:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 02:01:19 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Fri May 28 02:54:05 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 02:54:05 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 17:42:56 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> update FtpClient.java > > src/java.desktop/share/classes/java/awt/Component.java line 630: > >> 628: } >> 629: >> 630: @SuppressWarnings("removal") > > I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring > that was needed because of the usage in this static block and you could not apply the annotation here. > Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. > Can you explain ? There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From prr at openjdk.java.net Fri May 28 03:15:12 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 28 May 2021 03:15:12 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Component.java line 630: >> >>> 628: } >>> 629: >>> 630: @SuppressWarnings("removal") >> >> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring >> that was needed because of the usage in this static block and you could not apply the annotation here. >> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring. >> Can you explain ? > > There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. Ok. But I will quote you "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class" So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated. Why has the explanation changed ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Fri May 28 03:22:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 03:22:03 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 03:12:35 GMT, Phil Race wrote: >> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635. > > Ok. But I will quote you > "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class" > > So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated. > > Why has the explanation changed ? I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From dholmes at openjdk.java.net Fri May 28 06:49:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 06:49:04 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 16:56:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments as suggested by Dan. Hi Martin, I'm with @stefank. This special case is a race condition and the solution for that is Atomic::load/store. Given Atomic::load/store don't actually need to do anything in practice (other than act as marker of a race) I don't have any qualms about using them all the time. Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From ysuenaga at openjdk.java.net Fri May 28 07:10:06 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 07:10:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 15:19:59 GMT, Stefan Karlsson wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comments as suggested by Dan. > > I wonder if this should be changed to perform the read once by using Atomic::load? That's the guidance we've given the last few years. Some background for this: JDK-8234192. I agree with @stefank and @dholmes-ora . It is nature to happen the change in thread.hpp to fix this problem. > Seperately, I'm unclear why we allow this race to exist. I thought we took snapshots when threads were known to be safe and stable. But that is a separate issue. Now we have Thread-Local handshake. I think we should use it at here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From stefank at openjdk.java.net Fri May 28 07:15:01 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 28 May 2021 07:15:01 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Looks good. Could you verify the fix with ZGC? G1 doesn't use it, so testing with G1 will only show that we don't hit the failing assert anymore. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4217 From stefank at openjdk.java.net Fri May 28 07:24:37 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 28 May 2021 07:24:37 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7] In-Reply-To: References: Message-ID: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Review kbarrett - Review dholmes - Update HotSpot style guide documents - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Clean up assembler_.inline.hpp - 8267464: Circular-dependency resiliant inline headers ------------- Changes: https://git.openjdk.java.net/jdk/pull/4127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=06 Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From rehn at openjdk.java.net Fri May 28 07:30:11 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 28 May 2021 07:30:11 GMT Subject: RFR: 8265753: Remove manual JavaThread transitions to blocked [v7] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 14:45:07 GMT, Daniel D. Daugherty wrote: > Thumbs up. > > Reviewed the incremental between v05 -> v06. Looks good. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From rehn at openjdk.java.net Fri May 28 07:34:15 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 28 May 2021 07:34:15 GMT Subject: Integrated: 8265753: Remove manual JavaThread transitions to blocked In-Reply-To: References: Message-ID: On Wed, 5 May 2021 08:11:04 GMT, Robbin Ehn wrote: > Please consider this change which removes the manual transitions to blocked. > This adds a preprocess template/functor which is executed in the destructor of 'ThreadBlockInVM' if we are going to do any processing. > This gives us a way to backout of the object/raw monitor before suspend or other processing, such as a safepoint. > > The object monitor code could be straight forward changed to use this instead of manual transitions. > > Raw monitors on the other hand are a bit more complicated due to 'implicit' rules (consequences of the specs). > Added a comment in hpp trying to explain it; we cannot simply transition with a raw monitor held. > This caused the change in the destructor ~ThreadInVMfromNative() (this specific change have also been tested in unrelated exploration of transition), now this RAII does the same as we do when going to native from Java, just setting the state. > Since we are going from an unsafe state, in VM, to a safe state, in native, we do not need to check the poll. > That made it possible to careful use ThreadInVMfromNative in raw monitors. > > I also remove the early CAS in raw_enter. > We lock a lock to do a CAS, in the uncontended case means CAS on lock then CAS raw monitor. > Now we instead do a transitions, in the uncontended case means fence, CAS raw monitor, fence. > (multiple fence (CAS is also a fence) very close to each other have little additional performance impact on contemporary hardware) > > Passes t1-t7 and manual stressing relevant test groups. This pull request has now been integrated. Changeset: 97ec5ad0 Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/97ec5ad0a6ed2cd87a9c75b0559e9bb55b72121e Stats: 340 lines in 8 files changed: 119 ins; 150 del; 71 mod 8265753: Remove manual JavaThread transitions to blocked Reviewed-by: dcubed, rrich, dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/3875 From simonis at openjdk.java.net Fri May 28 08:36:09 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 28 May 2021 08:36:09 GMT Subject: RFR: 8267555: Fix class file version during redefinition after 8238048 [v2] In-Reply-To: References: <5O8oTX31pIM2SKKbpeL66Zz9NY3V_LRwvDd_CqWHdms=.f015c748-80f6-4db3-a8ce-faf0159b20ce@github.com> Message-ID: <8II7jI95WRg4a_7C-LgrZdQro-CTGErSHJlzvq-LQgc=.031c253b-f484-488e-8784-6d0240987b90@github.com> On Thu, 27 May 2021 21:28:00 GMT, Serguei Spitsyn wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267555: Fix class file version during redefinition after 8238048 > > Hi Volker, > The fix looks okay to me. > Thank you for fixing it! > Serguei Thanks for the reviews @sspitsyn and @coleenp. ------------- PR: https://git.openjdk.java.net/jdk/pull/4149 From simonis at openjdk.java.net Fri May 28 08:36:10 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 28 May 2021 08:36:10 GMT Subject: Integrated: 8267555: Fix class file version during redefinition after 8238048 In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:20:29 GMT, Volker Simonis wrote: > In jdk15, [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048) moved the class file versions from the `InstanceKlass` into the `ConstantPool` and introduced a new method `ConstantPool::copy_fields(const ConstantPool* orig)` which copies not only the `source_file_name_index`, `generic_signature_index` and `has_dynamic_constant` from `orig` to the current `ConstantPool` object, but also the minor and major class file version. > > This new `copy_fields()` method is now called during class redefinition (in `VM_RedefineClasses::merge_cp_and_rewrite()`) at places where previously only the `has_dynamic_constant` attribute was copied from the old to the new version of the class. If the new version of the class has a different class file version than the previous one, this different class file version will now be overwritten with the class file version of the previous, original class. > > In `VM_RedefineClasses::load_new_class_versions()`, after `VM_RedefineClasses::merge_cp_and_rewrite()` has completed, we do another verification step to check the results of constant pool merging (in jdk15 this was controlled by `VerifyMergedCPBytecodes` which was on by default, in jdk16 and later this extra verification step only happens in debug builds). If the new class instance uses features which are not available for the class version of the previous class, this verification step will fail. > > The solution is simple. Don't overwrite the class file version of the new class any more. This also requires reintroducing the update of the class file version for the newly redefined class in `VM_RedefineClasses::redefine_single_class()` like this was done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). > > I'm just not sure about the additional new field updates for `source_file_name_index` and `generic_signature_index` in `ConstantPool::copy_fields()` which were not done before [JDK-8238048](https://bugs.openjdk.java.net/browse/JDK-8238048). Do we want to preserve these attributes from the original class and write them into the new redefined version? If yes, the new code would be correct and we could remove the following code from `VM_RedefineClasses::redefine_single_class()` because that was already done in `ConstantPool::copy_fields()`: > > // Copy the "source file name" attribute from new class version > the_class->set_source_file_name_index( > scratch_class->source_file_name_index()); > > Otherwise the new would be wrong in the same sense like it was wrong for the class file versions. The differences of between the class file versions and `source_file_name_index`/`generic_signature_index` is that the former attributes are mandatory and therefor always available in the new class version while the latter ones are optional. So maybe we should only copy them from the original to the new class if they are not present there already? It currently seems like there's no optimal solution for these attributes? This pull request has now been integrated. Changeset: 1d2c7ac3 Author: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/1d2c7ac3f7492b335757bf0fd3f6ca3941c5fc72 Stats: 208 lines in 5 files changed: 204 ins; 1 del; 3 mod 8267555: Fix class file version during redefinition after 8238048 Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/4149 From mdoerr at openjdk.java.net Fri May 28 10:13:25 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 10:13:25 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/97a7df60..f4005ec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=01-02 Stats: 14 lines in 2 files changed: 3 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 10:19:04 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 10:19:04 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. Thanks, folks, for reviewing! Changed to use Atomic::load/store. With this version, we use volatile accesses to these two members consistently. This may restrict compiler optimizations a bit, but I wouldn't expect a performance problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Fri May 28 10:49:32 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 10:49:32 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Extend HeapDumpTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4183/files - new: https://git.openjdk.java.net/jdk/pull/4183/files/c3b4bc58..7faa6900 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=00-01 Stats: 12 lines in 2 files changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183 PR: https://git.openjdk.java.net/jdk/pull/4183 From akozlov at openjdk.java.net Fri May 28 11:01:05 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 11:01:05 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file In-Reply-To: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> References: <9mOfQ5-mxg39XJd4oaRdes-0Ci9C62DiHxjLlK5ohUo=.0ecf4b35-0090-4272-a8b1-1bd1cae3bf98@github.com> Message-ID: On Thu, 27 May 2021 13:57:05 GMT, Lin Zang wrote: > you may need to add test cases A test is trivial. Just in case, I've added it. > it seems the /csr label is required Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From lzang at openjdk.java.net Fri May 28 11:53:08 2021 From: lzang at openjdk.java.net (Lin Zang) Date: Fri, 28 May 2021 11:53:08 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Hi Anton, > Is the label really required? I don't see any integrated RFR with the label. I won't push this before CSR is approved anyway. AFAIK, the `csr` label will be removed by the `bot` when it gets approved. I usually add it in PR when CSR is required, and maybe it could help reviewer notice it and hence review the CSR. Also it could help guarantee the PR not to be pushed when CSR is not approved. BRs, Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From ysuenaga at openjdk.java.net Fri May 28 12:54:05 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 12:54:05 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:13:25 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > New solution: Use Atomic::load/store in current_pending/waiting_monitor accessors. Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From ysuenaga at openjdk.java.net Fri May 28 12:59:07 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 12:59:07 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest I think `-f` (force) is more suitable like `cp` on Linux - Maybe it should be discussed on CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From mdoerr at openjdk.java.net Fri May 28 13:15:29 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:15:29 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v4] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Make the 2 member fields volatile. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/f4005ec0..932a7dfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:25:23 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:25:23 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: whitespace fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/932a7dfd..c3e58884 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:25:24 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:25:24 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:51:26 GMT, Yasumasa Suenaga wrote: > Shouldn't we add `volatile` to both `_current_pending_monitor` and `_current_waiting_monitor`? Right. Done. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:30:14 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:30:14 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: <-N7ZeEqwfU4zlySMnBX3O8uBc01N9uWgqxRotI_Y7EQ=.e9cd29e9-6e78-4829-a1c6-6b2bea341280@github.com> On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > whitespace fix Thumbs up. Just a couple of suggestions about the comments. src/hotspot/share/runtime/thread.hpp line 757: > 755: ObjectMonitor* current_pending_monitor() { > 756: // Using atomic load to prevent compilers from reloading (ThreadService::get_current_contended_monitor). > 757: // In case of concurrent modification, reloading pointer after NULL check must be prevented. Perhaps rewrite the comment like this: // Use Atomic::load() to prevent data race between concurrent modification and // concurrent readers, e.g., ThreadService::get_current_contended_monitor(). src/hotspot/share/runtime/thread.hpp line 770: > 768: } > 769: ObjectMonitor* current_waiting_monitor() { > 770: // Using atomic load as in current_pending_monitor. Perhaps: `// See the comment in current_pending_monitor() above.` ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:42:30 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:42:30 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Improve comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4224/files - new: https://git.openjdk.java.net/jdk/pull/4224/files/c3e58884..49354d0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4224&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4224.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4224/head:pull/4224 PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:42:30 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:42:30 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 07:06:50 GMT, Yasumasa Suenaga wrote: > I thought we took snapshots when threads were known to be safe and stable. When we ask for snapshots with stack traces, we use a safepoint to get all of target thread's stack traces at the same time. Obviously that code path is safe. The "other" code path is when we don't ask for stack traces and that path has always been carefully coded to return non stack trace information in a safe manner, but it does not use a safepoint or a handshake. This duality in code paths is why the new test I wrote: serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java makes alternating calls of asking for the stack trace and then not. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Fri May 28 13:42:31 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 28 May 2021 13:42:31 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v5] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:25:23 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > whitespace fix Thanks for the review! I have improved the comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 13:50:15 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 13:50:15 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From stefank at openjdk.java.net Fri May 28 14:04:06 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 28 May 2021 14:04:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Looks good. Thanks! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From eosterlund at openjdk.java.net Fri May 28 15:34:06 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 28 May 2021 15:34:06 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Looks good, but please test with ZGC before integrating. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4217 From ysuenaga at openjdk.java.net Fri May 28 16:04:06 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 28 May 2021 16:04:06 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Marked as reviewed by ysuenaga (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Fri May 28 16:07:12 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 28 May 2021 16:07:12 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: <5t-TViZqHB79VDJSiOs4pY2wiYiIvwm35G5G7us7Rl8=.9ef26c20-d5fc-4a6b-b527-52d7db59cee6@github.com> On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest `-f` is overloaded with meanings in various Unix utilities, I'd like to keep it specific. For example, `cp -f` will actually do something different, it will delete the file and create a new one. `jcmd -rewrite` will reuse the same file. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From kvn at openjdk.java.net Fri May 28 18:17:57 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 28 May 2021 18:17:57 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v7] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 07:24:37 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers > - Review kbarrett > - Review dholmes > - Update HotSpot style guide documents > - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers > - Clean up assembler_.inline.hpp > - 8267464: Circular-dependency resiliant inline headers Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4127 From dcubed at openjdk.java.net Fri May 28 21:45:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 21:45:29 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers Message-ID: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. Also remove errant text added by the jframeID XSL template code: // java_thread - unchecked // depth - pre-checked as non-negative The first line about `jthread` is output in error. Only the second line about `depth` should be included. This fix is tested with a Mach5 Tier1 job set. ------------- Commit messages: - 8264800: cleanup Threads_lock comments in JVM/TI function headers Changes: https://git.openjdk.java.net/jdk/pull/4254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264800 Stats: 91 lines in 3 files changed: 0 ins; 52 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/4254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4254/head:pull/4254 PR: https://git.openjdk.java.net/jdk/pull/4254 From dholmes at openjdk.java.net Fri May 28 21:56:17 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 28 May 2021 21:56:17 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4224 From dcubed at openjdk.java.net Fri May 28 21:57:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 May 2021 21:57:31 GMT Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based Message-ID: The Thread-SMR project added counter based tests for various APIs. See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". Time based tests are more appropriate for stress kits so I'm updating the counter based tests to be time based instead. Two of the updated tests have shaken out failures that are tracked by: JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" These updated tests are test via Mach5 Tier[134567] (in progress). They have also been test by my Stress Kit runs for jdk-17+2[0-4]. ------------- Commit messages: - Use portable LL format from jni_tools.h for printf() with jlong. - 8266130: covert Thread-SMR stress tests from counter based to time based Changes: https://git.openjdk.java.net/jdk/pull/4237/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266130 Stats: 981 lines in 20 files changed: 396 ins; 291 del; 294 mod Patch: https://git.openjdk.java.net/jdk/pull/4237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4237/head:pull/4237 PR: https://git.openjdk.java.net/jdk/pull/4237 From duke at openjdk.java.net Fri May 28 22:42:22 2021 From: duke at openjdk.java.net (duke) Date: Fri, 28 May 2021 22:42:22 GMT Subject: Withdrawn: 8264311: Heap object statistics In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:04:57 GMT, Roman Kennke wrote: > For Lilliput evaluation, it would be useful to be able to get some statistics about heap objects, e.g. how many objects there typically are, what is their (average) size, how big is the live data set, how many objecs have an identity hash code and how many objects are locked. Some of that information may be useful for general purpose too, e.g. the avg live data set and object size/count information might be quite useful to have. > > Heap object statistics can be gathered and printed by invoking java with -XX:+UnlockDiagnosticVMOptions -XX:+HeapObjectStats -Xlog:heap+stats. It will impact performance of the workload. The sampling interval can be specificed by -XX:HeapObjectStatsSamplingInterval=X (in ms) and defaults to 500 (ms). > > Testing: > - [x] Some manual tests, verifying the plausability of the output by hand > - [ ] tier1 > - [ ] tier2 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3271 From ysuenaga at openjdk.java.net Sat May 29 01:22:21 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 29 May 2021 01:22:21 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Hmm... it looks like the same result for the user between `-f` and `-rewrite`, and also many users will be easy to imagine the result in case of `-f`. Let's see comments from other reviewers. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From dcubed at openjdk.java.net Sat May 29 13:46:22 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 13:46:22 GMT Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based In-Reply-To: References: Message-ID: On Fri, 28 May 2021 00:13:25 GMT, Daniel D. Daugherty wrote: > The Thread-SMR project added counter based tests for various APIs. > See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". > > Time based tests are more appropriate for stress kits so I'm > updating the counter based tests to be time based instead. > > Two of the updated tests have shaken out failures that are tracked by: > > JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" > > JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" > > These updated tests are tested via Mach5 Tier[134567]. > They have also been test by my Stress Kit runs for jdk-17+2[0-4]. Here are my Mach5 Tier[1-7] results: Mach5 Tier1: - no failures - 25 runs of the updated tests in Tier1 Mach5 Tier2: - 1 known, unrelated failure - The updated tests don't run in Tier2. Mach5 Tier3: - 5 known, unrelated test failures - 70 runs of the updated tests Mach5 Tier4: - 17 runs of the updated tests - 2 known, unrelated test failures Mach5 Tier5: - 56 runs of the updated tests - 1 known, unrelated failure, 3 failures of the updated tests linked to the known bugs Mach5 Tier6: - 122 runs of the updated tests - 2 failures of the updated tests, linked to the known bugs Mach5 Tier7: - 151 runs of the updated tests - 1 failure of the updated tests, linked to the known bug Because of the failures in the upper tiers, when this PR is integrated I will be ProblemListing: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java 8264605 vmTestbase/nsk/jvmti/PopFrame/popframe011/TestDescription.java 8266593 The suspendthrd003/8264605 failure had been seen one time in the CI on 2021.04.01 (April Fools Day!) and is now much more reproducible with the updated version. The popframe011/8266593 failure had never been seen before being updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4237 From coleenp at openjdk.java.net Sat May 29 15:50:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 29 May 2021 15:50:19 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Yes, looks trivial and fine. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4254 From dcubed at openjdk.java.net Sat May 29 16:35:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 29 May 2021 16:35:17 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: <_Xn-IYh41j6i8Zb_Nl6FpYElGoEFEo1blJBwIOUYoFY=.24dff08f-26f2-493a-a78e-a01f90fa8ab2@github.com> On Sat, 29 May 2021 15:47:02 GMT, Coleen Phillimore wrote: >> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. >> >> Also remove errant text added by the jframeID XSL template code: >> >> >> // java_thread - unchecked >> // depth - pre-checked as non-negative >> >> >> The first line about `jthread` is output in error. >> Only the second line about `depth` should be included. >> >> This fix is tested with a Mach5 Tier1 job set. > > Yes, looks trivial and fine. @coleenp - Thanks for the fast review! Do you think I should wait for a Serviceability team member review or just integrate? I _think_ they still trust me to change comments... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From prr at openjdk.java.net Sun May 30 17:44:23 2021 From: prr at openjdk.java.net (Phil Race) Date: Sun, 30 May 2021 17:44:23 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From rehn at openjdk.java.net Mon May 31 06:44:20 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 31 May 2021 06:44:20 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From stefank at openjdk.java.net Mon May 31 06:44:45 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 31 May 2021 06:44:45 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8] In-Reply-To: References: Message-ID: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Review kbarrett - Review dholmes - Update HotSpot style guide documents - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers - Clean up assembler_.inline.hpp - 8267464: Circular-dependency resiliant inline headers ------------- Changes: https://git.openjdk.java.net/jdk/pull/4127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4127&range=07 Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4127/head:pull/4127 PR: https://git.openjdk.java.net/jdk/pull/4127 From dholmes at openjdk.java.net Mon May 31 07:06:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 31 May 2021 07:06:20 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: <5XsEmp8-WkUG9TATjla1pIlWNXPS2r37n0sM6m3Of0A=.930f8486-4575-4367-abb0-d34ee9d74c35@github.com> On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Hi Dan, I _think_ this is okay. It is rather confusing though as I couldn't figure out why some functions have the threadsList-handle as part of the code generated via the XML file, and some have it in the jvmtiEnv part of the code - e.g. compare SetThreadLocalStorage and GetThreadLocalStorage. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4254 From mdoerr at openjdk.java.net Mon May 31 08:32:26 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 31 May 2021 08:32:26 GMT Subject: Integrated: 8267842: SIGSEGV in get_current_contended_monitor In-Reply-To: References: Message-ID: On Thu, 27 May 2021 09:56:22 GMT, Martin Doerr wrote: > We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. This pull request has now been integrated. Changeset: 1e29005a Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/1e29005a22c7951242cf3b0d8cf2e6adc0b7b315 Stats: 12 lines in 2 files changed: 4 ins; 0 del; 8 mod 8267842: SIGSEGV in get_current_contended_monitor Reviewed-by: stefank, dcubed, ysuenaga, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From mdoerr at openjdk.java.net Mon May 31 08:32:26 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 31 May 2021 08:32:26 GMT Subject: RFR: 8267842: SIGSEGV in get_current_contended_monitor [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote: >> We need a fix for crashes in get_current_contended_monitor due to concurrent modification of memory locations which are not declared volatile. See bug for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/4224 From akozlov at openjdk.java.net Mon May 31 08:38:23 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 31 May 2021 08:38:23 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest Agree, I would like to hear more feedback. I still don't think we need to provide a (false) similarity with existing tools. For example: * `cp` succeeds if the target file exists; `jcmd` bails out in this case * `cp -f` unlinks and creates a new file (so it is just a convenient substitution to `rm -f; cp`); `jcmd -rewrite` rewrites the file -- this cannot be achieved without making changes to the Hotspot. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From stefank at openjdk.java.net Mon May 31 09:02:31 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 31 May 2021 09:02:31 GMT Subject: RFR: 8267464: Circular-dependency resilient inline headers [v8] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 06:44:45 GMT, Stefan Karlsson wrote: >> I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. >> >> This is a small, contrived example to show the problem: >> >> // a.hpp >> #pragma once >> >> void a1(); >> void a2(); >> >> >> // a.inline.hpp >> #pragma once >> >> #include "a.hpp" >> #include "b.inline.hpp" >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> >> // b.hpp >> #pragma once >> >> void b1(); >> void b2(); >> >> >> // b.inline.hpp >> #pragma once >> >> #include "a.inline.hpp" >> #include "b.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> The following code compiles fine: >> >> // a.cpp >> #include "a.inline.hpp" >> >> int main() { >> a1(); >> >> return 0; >> } >> >> But the following: >> >> // b.cpp >> #include "b.inline.hpp" >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> fails with the this error message: >> >> In file included from b.inline.hpp:3, >> from b.cpp:1: >> a.inline.hpp: In function ?void a1()?: >> a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? >> >> We can see the problem with g++ -E: >> >> # 1 "a.inline.hpp" 1 >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 4 "b.inline.hpp" 2 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> >> b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). >> >> This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. >> >> I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. >> >> In the example above, b.inline.hpp would become: >> >> // b.inline.hpp >> #pragma once >> >> #include "b.hpp" >> #include "a.inline.hpp" >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> and now both a.cpp and b.cpp compiles. The generated output now looks like this: >> >> # 1 "b.inline.hpp" 1 >> # 1 "b.hpp" 1 >> >> void b1(); >> void b2(); >> >> # 4 "b.inline.hpp" 2 >> # 1 "a.inline.hpp" 1 >> >> # 1 "a.hpp" 1 >> >> void a1(); >> void a2(); >> >> # 4 "a.inline.hpp" 2 >> >> inline void a1() { >> b1(); >> } >> >> inline void a2() { >> } >> >> # 5 "b.inline.hpp" 2 >> >> inline void b1() { >> } >> >> inline void b2() { >> a1(); >> } >> >> # 2 "b.cpp" 2 >> >> int main() { >> b1(); >> >> return 0; >> } >> >> The declarations come first, and the compiler is happy. >> >> An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. >> >> Some notes about this patch: >> 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. >> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. >> 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. >> 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. >> 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. >> >> What do you think? > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers > - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers > - Review kbarrett > - Review dholmes > - Update HotSpot style guide documents > - Merge remote-tracking branch 'origin/master' into 8267464_circular-dependency_resilient_inline_headers > - Clean up assembler_.inline.hpp > - 8267464: Circular-dependency resiliant inline headers Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From stefank at openjdk.java.net Mon May 31 09:02:32 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 31 May 2021 09:02:32 GMT Subject: Integrated: 8267464: Circular-dependency resilient inline headers In-Reply-To: References: Message-ID: On Thu, 20 May 2021 11:55:05 GMT, Stefan Karlsson wrote: > I'd like to propose a small adjustment to how we write .inline.hpp files, in the hope to reduce include problems because of circular dependencies between inline headers. > > This is a small, contrived example to show the problem: > > // a.hpp > #pragma once > > void a1(); > void a2(); > > > // a.inline.hpp > #pragma once > > #include "a.hpp" > #include "b.inline.hpp" > > inline void a1() { > b1(); > } > > inline void a2() { > } > > > // b.hpp > #pragma once > > void b1(); > void b2(); > > > // b.inline.hpp > #pragma once > > #include "a.inline.hpp" > #include "b.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > The following code compiles fine: > > // a.cpp > #include "a.inline.hpp" > > int main() { > a1(); > > return 0; > } > > But the following: > > // b.cpp > #include "b.inline.hpp" > > int main() { > b1(); > > return 0; > } > > > fails with the this error message: > > In file included from b.inline.hpp:3, > from b.cpp:1: > a.inline.hpp: In function ?void a1()?: > a.inline.hpp:8:3: error: ?b1? was not declared in this scope; did you mean ?a1?? > > We can see the problem with g++ -E: > > # 1 "a.inline.hpp" 1 > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 4 "b.inline.hpp" 2 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > > b1() is called before it has been declared. b.inline.hpp inlined a.inline.hpp, which uses functions declared in b.hpp. However, at that point we've not included enough of b.inline.hpp to have declared b1(). > > This is a small and easy example. In the JVM the circular dependencies usually involves more than two files, and often from different sub-systems of the JVM. We have so-far solved this by restructuring the code, making functions out-of-line, creating proxy objects, etc. However, the more we use templates, the more this is going to become a reoccurring nuisance. And in experiments with lambdas, which requires templates, this very quickly showed up as a problem. > > I propose that we solve most (all?) of these issues by adding a rule that states that .inline.hpp files should start by including the corresponding .hpp, and that the .hpp should contain the declarations of all externally used parts of the .inline.hpp file. This should guarantee that the declarations are always present before any subsequent include can create a circular include dependency back to the original file. > > In the example above, b.inline.hpp would become: > > // b.inline.hpp > #pragma once > > #include "b.hpp" > #include "a.inline.hpp" > > inline void b1() { > } > > inline void b2() { > a1(); > } > > and now both a.cpp and b.cpp compiles. The generated output now looks like this: > > # 1 "b.inline.hpp" 1 > # 1 "b.hpp" 1 > > void b1(); > void b2(); > > # 4 "b.inline.hpp" 2 > # 1 "a.inline.hpp" 1 > > # 1 "a.hpp" 1 > > void a1(); > void a2(); > > # 4 "a.inline.hpp" 2 > > inline void a1() { > b1(); > } > > inline void a2() { > } > > # 5 "b.inline.hpp" 2 > > inline void b1() { > } > > inline void b2() { > a1(); > } > > # 2 "b.cpp" 2 > > int main() { > b1(); > > return 0; > } > > The declarations come first, and the compiler is happy. > > An alternative to this, that has been proposed by other HotSpot GC devs have been to always include all .hpp files first, and then have a section of .inline.hpp includes. I've experimented with that as well, but I think it requires more maintenance and vigilance of *users* .inline.hpp files (add .hpp include to the first section, add .inline.hpp section to second). The proposed structures only requires extra care from *writers* of .inline.hpp files. All others can include .hpp and .inline.hpp as we've been doing for a long time now. > > Some notes about this patch: > 1) Some externally-used declarations have been placed in .inline.hpp files, and not in the .hpp. Those should be moved. I have not done that. > 2) Some .inline.hpp files don't have a corresponding .hpp file. I could either try to fix that in this patch, or we could take care of that as separate patches later. > 3) The style I chose was to add the .hpp include and a extra blank line, separating it from the rest of the includes. I think I like that style, because it makes it easy for those writing .inline.hpp to recognize this pattern. And it removes the confusion why this include isn't sorted into the other includes. > 4) We have a few *special* platform dependent header files. Both those that simply are included into platform independent files, and those that inject code *into* the platform independent classes. Extra care, as always, need to be taken around those files. > 5) Mostly tested locally, but I'll test on more platforms if the idea is accepted. > > What do you think? This pull request has now been integrated. Changeset: 64f0f689 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/64f0f68958a74d4ee34c4b738759fc2278fa8b47 Stats: 490 lines in 242 files changed: 349 ins; 118 del; 23 mod 8267464: Circular-dependency resilient inline headers Reviewed-by: kbarrett, eosterlund, dholmes, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/4127 From weijun at openjdk.java.net Mon May 31 15:02:57 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:02:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: default behavior reverted to allow ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05 Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 31 15:09:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:09:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From lancea at openjdk.java.net Mon May 31 16:24:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 31 May 2021 16:24:24 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com> On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073