From alanb at openjdk.java.net  Tue Jun  1 12:50:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 12:50:29 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: <dVFpffOKyZHh8laXoFtu1wOUx8nLCS9d12qsoSUE5Bk=.632c4211-41df-40b4-8e07-ee8c3cb249f5@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> 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

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the  middle of the declaration?

The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue Jun  1 15:06:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:06:41 GMT
Subject: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal [v7]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <DSVYh67KJe9RW8wMcOpG0R8F4Jx4HYzwW66XEV-EH1w=.cb0b76eb-c433-4ed1-bf62-e227082768f3@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:

  rename setSecurityManagerDirect to implSetSecurityManager

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06

  Stats: 5 lines in 1 file changed: 0 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 Jun  1 15:21:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:21:33 GMT
Subject: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal [v8]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@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 with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - 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
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 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 alanb at openjdk.java.net  Tue Jun  1 16:05:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 16:05:29 GMT
Subject: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <M0Mj0BK_4OBlu3dwDgSWnaM8KDpkL0KxAJldFL7q-eY=.31a0aa64-5a69-42df-bf80-09b4e7a3c144@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> 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 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - 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
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From joehw at openjdk.java.net  Tue Jun  1 16:28:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Jun 2021 16:28:27 GMT
Subject: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <rwSPwilSFt5efKcqrbureXYq8SmLxHMgrE_psXV-S9A=.87124c9e-112f-4a4e-80de-26bfa32fa995@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> 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 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - 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
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From sgehwolf at openjdk.java.net  Wed Jun  2 09:09:44 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 09:09:44 GMT
Subject: jmx-dev RFR: 8268103: JNI functions incorrectly return a double
 after JDK-8265836
Message-ID: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>

Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.

Thoughts?

-------------

Commit messages:
 - 8268103: JNI functions incorrectly return a double after JDK-8265836

Changes: https://git.openjdk.java.net/jdk/pull/4300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268103
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4300/head:pull/4300

PR: https://git.openjdk.java.net/jdk/pull/4300

From github.com+7947546+tanghaoth90 at openjdk.java.net  Wed Jun  2 09:54:50 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Wed, 2 Jun 2021 09:54:50 GMT
Subject: jmx-dev RFR: 8268103: JNI functions incorrectly return a double
 after JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <Em1ngjJV2nDCUMTeAHAIve72r3Csf4oam5-4dj8CNpk=.e0962a95-b4e6-4c4a-b948-6b875dedff2e@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

LGTM. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4300

From dholmes at openjdk.java.net  Wed Jun  2 10:50:26 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Jun 2021 10:50:26 GMT
Subject: jmx-dev RFR: 8268103: JNI functions incorrectly return a double
 after JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <5yE8noyq7DePsxoL58O_yLsbr8K21ls__pwoDNUz1Z8=.49d4fa37-dd80-4fab-b02b-e0fe44e6dc8d@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

Looks good and trivial.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4300

From weijun at openjdk.java.net  Wed Jun  2 12:01:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:30 GMT
Subject: jmx-dev RFR: 8266459: Implement JEP 411: Deprecate the Security
 Manager for Removal [v9]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <HOkSwSOf7m0eP71_pjxacSX3FnXw8CbONP_DbY0mCno=.969b9543-c6d1-4001-afac-d8cb337fd60f@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 with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - 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
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 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  Wed Jun  2 12:01:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:33 GMT
Subject: jmx-dev Integrated: 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: <PsbFcEhvCahb4zpsvIhOlxvAbJK7DTE3-umT3Nsn5dY=.fe038b5f-dc17-4d4f-a19b-ed8c238c7d58@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 6765f902
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats:     2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:38 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:38 GMT
Subject: jmx-dev RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <PSyJvVFJ9ZdvF7KLSUwpd2ZUNj_zgTnlnfb894o0s2M=.3d72b382-7e1c-45b4-b704-541e57dfab0e@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> 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

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From sgehwolf at openjdk.java.net  Wed Jun  2 12:21:32 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 12:21:32 GMT
Subject: jmx-dev RFR: 8268103: JNI functions incorrectly return a double
 after JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <Qz3qX1Tkwb8DJRXhc_fc6bkbgukLR-gYQpzOlHvm27s=.98147c20-28a9-4749-bc38-7dbe8a2fa369@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4300

From sgehwolf at openjdk.java.net  Wed Jun  2 12:21:32 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 2 Jun 2021 12:21:32 GMT
Subject: jmx-dev Integrated: 8268103: JNI functions incorrectly return a
 double after JDK-8265836
In-Reply-To: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
References: <1mubcwecRPPkvEmGDA99NufAiufleQQEF1Yok9pWXlY=.bc410245-8ac4-4e7e-8d86-6666c65535d5@github.com>
Message-ID: <3NIPQxaFV9KfRRTk4r1hKez24s2FvhS4TmNz_ovJlzQ=.5c269af8-23cc-429a-9814-d527e7c06efe@github.com>

On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial patch.  Stubs should return `-1` for `jlong` rather than `-1.0` (`double`) on aix/macosx.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 2963c9e6
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2963c9e6778b95f5c0fc4298064a21d1e8f31b91
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8268103: JNI functions incorrectly return a double after JDK-8265836

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/4300

From weijun at openjdk.java.net  Wed Jun  2 15:40:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:40:55 GMT
Subject: jmx-dev RFR: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K [v4]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <iWLNwxV2CvTVXj57-NbeWHor64Ab3P7461jOk1XxoJ0=.91556668-25eb-40b4-afae-730f9c1d621f@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains one commit:

  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=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 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  Wed Jun  2 15:51:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:33 GMT
Subject: jmx-dev Integrated: 8267521: Post JEP 411 refactoring: maximum
 covering > 50K
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <zkd_bofYu1MISkzzGFuI8utKnvp_M7M4icu-ws3be7k=.d7621e87-5890-492f-a64a-187e1f9eb9ed@github.com>

On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang <weijun at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 508cec75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats:     245 lines in 18 files changed: 140 ins; 39 del; 66 mod

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 03:14:26 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 03:14:26 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
Message-ID: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>

If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

-------------

Commit messages:
 - Fix the dead loop.\nSummary: If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

Changes: https://git.openjdk.java.net/jdk/pull/4378/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268361
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4378/head:pull/4378

PR: https://git.openjdk.java.net/jdk/pull/4378

From yyang at openjdk.java.net  Tue Jun  8 03:14:26 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 8 Jun 2021 03:14:26 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <TdWCAblzM0aCc-1wo7hH8MG-MoR1nWg8PIHuLzI8Sig=.046467a4-0c3a-4f0c-8836-0d030d651644@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

I have encountered a similar problem before, I've filed a new issue https://bugs.openjdk.java.net/browse/JDK-8268361 for this. You can change your title to "8268361: Fix the infinite loop in next_line", then OpenJDK bot would associate your PR with the corresponding JBS issue.

Best regards,
Yang

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From dholmes at openjdk.java.net  Tue Jun  8 06:43:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 06:43:15 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
Message-ID: <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>

On Tue, 8 Jun 2021 06:35:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:
> 
>> 68:     do {
>> 69:         c = fgetc(f);
>> 70:     } while(c != '\n' && c != EOF);
> 
> Style nit: please add space before (

It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From dholmes at openjdk.java.net  Tue Jun  8 06:43:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Jun 2021 06:43:14 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

Hi,

This fixes the potential infinite loop, but is it sufficient?

Thanks,
David

src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:

> 68:     do {
> 69:         c = fgetc(f);
> 70:     } while(c != '\n' && c != EOF);

Style nit: please add space before (

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From sgehwolf at openjdk.java.net  Tue Jun  8 08:42:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Jun 2021 08:42:15 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 15:44:34 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 15:44:34 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <Uvl087fs2EtaHdhrWic3VZt3yMADOypq0zP7Xy9hUpw=.b326aa44-4ffb-4948-82ff-202198c86f43@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine has updated the pull request incrementally with one additional commit since the last revision:

  8268361: Fix the infinite loop in next_line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/ba53f913..c055e977

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4378/head:pull/4378

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:24:18 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:24:18 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
Message-ID: <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>

On Tue, 8 Jun 2021 06:39:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c line 70:
>> 
>>> 68:     do {
>>> 69:         c = fgetc(f);
>>> 70:     } while(c != '\n' && c != EOF);
>> 
>> Style nit: please add space before (
>
> It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?

In my case,  it happened in the container environment.
the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:31:20 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:31:20 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
Message-ID: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>

On Tue, 8 Jun 2021 08:39:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
> 
> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?

In my case, it happened in the container environment.
the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
It was caused by a lxcfs-3.1.2 segment fault's exit

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Tue Jun  8 16:46:16 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Tue, 8 Jun 2021 16:46:16 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
Message-ID: <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>

On Tue, 8 Jun 2021 16:21:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> It is not obvious to me that the caller of next_line will handle the fact that we have hit EOF?
>
> In my case,  it happened in the container environment.
> the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
> Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
> ![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)

I use  top -Hp $PID command and the thread show 100% cpu usage
![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From sgehwolf at openjdk.java.net  Wed Jun  9 07:32:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 9 Jun 2021 07:32:15 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v2]
In-Reply-To: <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
 <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
Message-ID: <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>

On Tue, 8 Jun 2021 16:43:14 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> In my case,  it happened in the container environment.
>> the /proc filesystem of the container is provided by  lxcfs, but a lxcfs bug may make the /proc/stat mount point change, then  the file descriptor is different and fgetc function returns an EOF on error,  But c != '\n' is true and it leads to the  infinit loop.
>> Below are our flamegraph in the production , it happends on serveral frameworks?micrometer, elasticsearch..?which use the api "sun/management/OperatingSystemImpl.getSystemCpuLoad"
>> ![107140246-bb490f80-695b-11eb-9f62-0116079f4f4a](https://user-images.githubusercontent.com/1964054/121218982-d5690f00-c8b5-11eb-8c1e-e39f2f2bc6a5.jpg)
>
> I use  top -Hp $PID command and the thread show 100% cpu usage
> ![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
> ![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)

@UncleNine We should handle the case in the `get_totalticks()` function - which seems to be the only user of `next_line()` - when `next_line()` returns EOF as David said. One way would be to return the 'c' character read in `next_line` and if it's EOF, return -2 in `get_totalticks()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:09:37 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:09:37 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v3]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <FUbtXALUOytoD_DmDcmIp77KP60JDs4xQCAUi8nxbQw=.8d0f3842-0f48-4066-8492-44a5a093141a@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine has updated the pull request incrementally with one additional commit since the last revision:

  8268361: Fix the infinite loop in next_line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/c055e977..3d50b052

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=01-02

  Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4378/head:pull/4378

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:45:35 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:45:35 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8268361: Fix the infinite loop in next_line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/3d50b052..e4f90ebd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4378/head:pull/4378

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Wed Jun  9 14:45:36 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Wed, 9 Jun 2021 14:45:36 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <RejAVYlargsPJqP3EIZIb_H2ss-CE-JRrraqRKBmq48=.dfce9dbe-ee5e-4ccb-9ff6-b9b425de7cc3@github.com>
 <F5BItDZgqkY0GpLSzI_6Z9EjCeV1wZ0FlBRnhFOm_WU=.07f2e35a-9799-46f1-a879-e1490c8c7d7b@github.com>
 <MEo4khAi-y8QnCxSFDBc11oQtjEPOQbEdjbnW7OCh8s=.8c4cf2e9-c35e-4a32-a54c-989d47f76ed0@github.com>
 <55ZNjLWzmvlo5e-eH1VKn_xBlfnRbPCKmgqydQn5qss=.813a0710-8cd8-4e92-a585-9f2b455bd798@github.com>
 <7mLfV22GjOXUNdaFPt1fflgzLBN8rtD_7073Is9v_-k=.8ad5ecf6-088e-4539-9448-0aa390f125af@github.com>
Message-ID: <-s5oeOAXyHEVZoWYK2aNwMzbH8LmM2TFT1xEC2B6zV0=.8a15d421-58e6-4f29-91c0-31f5e2ca6ad2@github.com>

On Wed, 9 Jun 2021 07:29:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I use  top -Hp $PID command and the thread show 100% cpu usage
>> ![top](https://user-images.githubusercontent.com/1964054/121224786-7ad2b180-c8bb-11eb-8c1b-e32b131d4327.png)
>> ![jtack](https://user-images.githubusercontent.com/1964054/121224813-81612900-c8bb-11eb-80e1-29d15989dc17.png)
>
> @UncleNine We should handle the case in the `get_totalticks()` function - which seems to be the only user of `next_line()` - when `next_line()` returns EOF as David said. One way would be to return the 'c' character read in `next_line` and if it's EOF, return -2 in `get_totalticks()`.

all right, i have updated the code

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From sgehwolf at openjdk.java.net  Wed Jun  9 17:38:15 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 9 Jun 2021 17:38:15 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <s_6HegW6p8Bfl0GnqUV2bPcO64rG98pMwVmbbaB45z8=.4b96e863-e5a8-4d5d-bc8e-dd6d87ed8e2e@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Looks fine to me. Please fix the jcheck (whitespace) issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From sspitsyn at openjdk.java.net  Wed Jun  9 18:36:20 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 9 Jun 2021 18:36:20 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <9XV5_MELiQdZofY1LZqxX1GvxAxa431iclFTH_WqPZk=.a2796991-e01a-4997-9e9c-5532a0a25da5@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

It looks okay to me.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4378

From dholmes at openjdk.java.net  Thu Jun 10 05:14:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Jun 2021 05:14:15 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v4]
In-Reply-To: <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <gqBkpiMlTD34YfMU-AnLty9QluOHXOnKTeq8OYmBu1o=.82dfc0c6-7982-4403-abdc-c0d1634e6aac@github.com>
Message-ID: <f81moO3cqkO0eW_h7NmNq5pEOrn9_Y79hCsCZyrNnJs=.fa6ef71e-edbf-4051-b562-1b3c2581f7e1@github.com>

On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

This seems better to me now.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Thu Jun 10 12:28:37 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Thu, 10 Jun 2021 12:28:37 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8268361: Fix the infinite loop in next_line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4378/files
  - new: https://git.openjdk.java.net/jdk/pull/4378/files/e4f90ebd..f5684062

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4378&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4378/head:pull/4378

PR: https://git.openjdk.java.net/jdk/pull/4378

From sspitsyn at openjdk.java.net  Thu Jun 10 14:45:55 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 10 Jun 2021 14:45:55 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <auRIymbWi9siOPH6Mb2zdsQqupQiFuMqR7SiHCO_Y3g=.5bf75b4f-909c-4199-b632-3b7c64000883@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8268361: Fix the infinite loop in next_line

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From sgehwolf at openjdk.java.net  Thu Jun 10 14:53:50 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 10 Jun 2021 14:53:50 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <In8ypWYhiVQ-x8xsFAgGPD_6eaTKcWeZ-jU7ppejNAA=.7da1adb3-54eb-46e9-92d7-91bff18385da@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8268361: Fix the infinite loop in next_line

LGTM. Thanks for your patience!

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Thu Jun 10 16:44:09 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Thu, 10 Jun 2021 16:44:09 GMT
Subject: jmx-dev Integrated: 8268361: Fix the infinite loop in next_line
In-Reply-To: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
Message-ID: <QhiomFYy9kvqtflAKLYC5uwL5rO5Ju6KpqO5AiCR43I=.379d2f6f-8aa2-4023-9fce-b48e0242d71b@github.com>

On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.

This pull request has now been integrated.

Changeset: 72672277
Author:    UncleNine <ganjianxuan at hotmail.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72672277e4dddf8e72f1c705cd5f57de40745635
Stats:     15 lines in 1 file changed: 11 ins; 0 del; 4 mod

8268361: Fix the infinite loop in next_line

Reviewed-by: dholmes, sgehwolf, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From dholmes at openjdk.java.net  Fri Jun 11 05:57:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Jun 2021 05:57:52 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
Message-ID: <Kv8KnBc7lUvbzDI5UI3IBkwPnDaAS4YhCSUFAssV4UM=.d02beb23-121d-4654-8020-7ec24f0d9559@github.com>

On Tue, 8 Jun 2021 16:28:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
>
>> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
> 
> In my case, it happened in the container environment.
> the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
> It was caused by a lxcfs-3.1.2 segment fault's exit

@UncleNine  please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From stuefe at openjdk.java.net  Fri Jun 11 06:12:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Jun 2021 06:12:54 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
Message-ID: <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>

On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8268361: Fix the infinite loop in next_line

Would it not be better to read the whole content of /proc/stat with a single read() call instead of line by line? I don't think proc fs guarantees any kind of consistency with separate reads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:07:00 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:07:00 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
 <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>
Message-ID: <NPSNhchp8XP_NVSZXAY7Bg3sL027TbUVPqhYkGt_vP4=.52547659-4297-41dd-9191-d2322e417821@github.com>

On Mon, 14 Jun 2021 14:00:14 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

> @UncleNine please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

Sorry,

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:07:00 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:07:00 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line
In-Reply-To: <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <wlUAvbk9Fxp8FgJT6kR2vyK2kqrazRRj9wAWBcUDuRI=.7c9f7840-3432-4245-9bcd-b7be877af9f3@github.com>
 <xDqx3mu0K5v6SDQxTE59yAt8jxA0qnBIItZtfz8N-ww=.8b92b307-c892-4a8c-837a-bf61d39a42cd@github.com>
Message-ID: <RM40ozyMx72Gu1gOh4VjlQxZZcYzXEjPlsWNll-1xco=.104ff07a-7b2c-4558-833e-c32444a3c458@github.com>

On Tue, 8 Jun 2021 16:28:34 GMT, UncleNine <github.com+1964054+UncleNine at openjdk.org> wrote:

>>> If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
>
>> > If the /proc/stat mount point is changed in container environment, the while loop may lead to 100% cpu usage.
>> 
>> In what way have you observed /proc/stat being changed which manifests in 100% cpu usage?
> 
> In my case, it happened in the container environment.
> the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug may make the /proc/stat mount point change.
> It was caused by a lxcfs-3.1.2 segment fault's exit

> @UncleNine please do not force push commits to an open PR as it makes it difficult for reviewers to track the changes. The PR can contain as many commits as you like as it will all be squashed to a single clean commit when integrating. Thanks.

Sorry,

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378

From github.com+1964054+unclenine at openjdk.java.net  Mon Jun 14 14:14:55 2021
From: github.com+1964054+unclenine at openjdk.java.net (UncleNine)
Date: Mon, 14 Jun 2021 14:14:55 GMT
Subject: jmx-dev RFR: 8268361: Fix the infinite loop in next_line [v5]
In-Reply-To: <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>
References: <IilN0c3D5vWjVp7opyb27QYlM4k8sSOGX65zAQwwM3o=.9077c85f-8b0c-4fc3-a0bc-0cab2da4d3e0@github.com>
 <1RjeocciCDIlMyxlfEuUvFwx_f0kaCrb_RezlPnMlWE=.154400be-5c2f-4d0d-9082-823c068c335e@github.com>
 <E1tsE1XsM61cTlwRahGwdd6WjJuJ8OtlycQxjk5lMkg=.f876d177-de2a-43c8-b38d-44bd4bb4a8c4@github.com>
Message-ID: <d9HyTfm_vmuR8F3HfrwluRQojY42fZ-QUqtoYkiv1wY=.56d8485a-4628-447f-99f9-9901e479b282@github.com>

On Fri, 11 Jun 2021 06:10:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Would it not be better to read the whole content of /proc/stat with a single read() call instead of line by line? I don't think proc fs guarantees any kind of consistency with separate reads.

yes, so fgetc's return value should need to be checked

-------------

PR: https://git.openjdk.java.net/jdk/pull/4378