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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 18:03:16 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 26 May 2021 18:03:16 GMT Subject: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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