From lmesnik at openjdk.java.net Tue Jun 1 02:59:19 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Jun 2021 02:59:19 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace I verified that async-profiles works with ZGC and data look reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From lmesnik at openjdk.java.net Tue Jun 1 03:03:22 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Jun 2021 03:03:22 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: On Thu, 27 May 2021 23:07:02 GMT, David Holmes wrote: >> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace > > src/hotspot/share/prims/forte.cpp line 326: > >> 324: int loop_count; >> 325: int loop_max = MaxJavaStackTraceDepth * 2; >> 326: RegisterMap map(thread, false, false); > > Can we add some comments as to what the false parameters mean please. > > RegisterMap map(thread, false /* no update */, false /*no stackwatermark frame processing */); > > Though it may be that a more elaborate block comment is needed to explain why we don't want stackwatermark frame processing. Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc. They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From eosterlund at openjdk.java.net Tue Jun 1 04:12:20 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 1 Jun 2021 04:12:20 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com> On Tue, 1 Jun 2021 03:00:23 GMT, Leonid Mesnik wrote: > Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc. They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking. You could say something generic like "StackWatermark can only be used when at points where the stack can be parsed by the GC", or something like that. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From lmesnik at openjdk.java.net Tue Jun 1 04:26:16 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Jun 2021 04:26:16 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com> References: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com> Message-ID: On Tue, 1 Jun 2021 04:09:13 GMT, Erik ?sterlund wrote: >> Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc. They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking. > >> Let me check with Erik if it makes sense to put more generic comments about the usage of stackwatermark frame processing in RegisterMap, frames etc. They can't be updated in an arbitrary thread state. It makes sense describe this info in stackwatermarking. > > You could say something generic like "StackWatermark can only be used when at points where the stack can be parsed by the GC", or something like that. Thank you for your prompt response. I meant that it makes sense to update comments for RegisterMap to mention this. Currently, the doc says how to use it and how to disable update: "Updating of the RegisterMap can be turned off by instantiating the // register map as: RegisterMap map(thread, false);" But it says nothing about why and how process_frames should be set. It might make sense to put this info there so anyone could easily find and read it. I think it is better to put it there rather than in forte.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From eosterlund at openjdk.java.net Tue Jun 1 05:05:24 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 1 Jun 2021 05:05:24 GMT Subject: RFR: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: <0OCkOjLl2iUz5Knd6Y246N_HB9rJGHTOInAjqro49S4=.e88b2d28-4a5f-42e3-885d-3304e3ba096d@github.com> Message-ID: <5lUwO4aIv9dQqDNbZ-T_EGzr9ui-Lwj33dbaQuj5lyw=.54a7475e-c352-4463-b2a1-cb92cf600e48@github.com> On Tue, 1 Jun 2021 04:23:43 GMT, Leonid Mesnik wrote: > Thank you for your prompt response. I meant that it makes sense to update comments for RegisterMap to mention this. Currently, the doc says how to use it and how to disable update: > > "Updating of the RegisterMap can be turned off by instantiating the > > // register map as: RegisterMap map(thread, false);" > > But it says nothing about why and how process_frames should be set. > > It might make sense to put this info there so anyone could easily find and read it. I think it is better to put it there rather than in forte.cpp. Yes I agree - that does make sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 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: 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 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: 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: > 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: 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: > 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: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 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 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: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 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 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 sspitsyn at openjdk.java.net Tue Jun 1 17:18:20 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 1 Jun 2021 17:18:20 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From cjplummer at openjdk.java.net Tue Jun 1 17:54:19 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Jun 2021 17:54:19 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 In-Reply-To: References: Message-ID: On Mon, 17 May 2021 12:07:13 GMT, Yasumasa Suenaga wrote: > Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). > > * serviceability/sa/ClhsdbDumpheap.java > * serviceability/sa/ClhsdbFindPC.java > * serviceability/sa/ClhsdbInspect.java > * serviceability/sa/ClhsdbSymbol.java > * serviceability/sa/TestHeapDumpForInvokeDynamic.java > * serviceability/sa/TestJmapCore.java > * serviceability/sa/TestJmapCoreMetaspace.java > > They need to handle relocated objects and/or live regions (pages). SA should handle them. > > This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help? Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4057 From lmesnik at openjdk.java.net Tue Jun 1 18:09:28 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Jun 2021 18:09:28 GMT Subject: Integrated: 8265148: StackWatermarkSet being updated during AsyncGetCallTrace In-Reply-To: References: Message-ID: <6wsQ5S6b38LKJaHo7R6aZrmjWgXDVILskv-sRMTT-vc=.3461dbbb-9dda-4d42-8349-c4108c29026c@github.com> On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote: > 8265148: StackWatermarkSet being updated during AsyncGetCallTrace This pull request has now been integrated. Changeset: 2b338355 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/2b3383557f71ede15d00bd87742a277c0c764d20 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8265148: StackWatermarkSet being updated during AsyncGetCallTrace Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/4217 From dcubed at openjdk.java.net Tue Jun 1 18:55:26 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 1 Jun 2021 18:55:26 GMT Subject: RFR: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: <1FMAjSHJcGt2gZuT15gF1iqH2_Cnc3U821a7ZFmcSNw=.249cc22c-e982-4fa2-bd94-3e3ddc818cfd@github.com> On Mon, 31 May 2021 06:41:29 GMT, Robbin Ehn wrote: >> A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. >> >> Also remove errant text added by the jframeID XSL template code: >> >> >> // java_thread - unchecked >> // depth - pre-checked as non-negative >> >> >> The first line about `jthread` is output in error. >> Only the second line about `depth` should be included. >> >> This fix is tested with a Mach5 Tier1 job set. > > Marked as reviewed by rehn (Reviewer). @robehn, @dholmes-ora and @sspitsyn - Thanks for the reviews! > It is rather confusing though as I couldn't figure out why some functions > have the threadsList-handle as part of the code generated via the XML > file, and some have it in the jvmtiEnv part of the code - e.g. compare > SetThreadLocalStorage and GetThreadLocalStorage. That would be an historical question for Robert Field. :-) Definitely not something I want to deal with in this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From dcubed at openjdk.java.net Tue Jun 1 18:55:27 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 1 Jun 2021 18:55:27 GMT Subject: Integrated: 8264800: cleanup Threads_lock comments in JVM/TI function headers In-Reply-To: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> References: <447m-AICa7xC_6cRKXXRoAqAfAaW6RcZ32-EEkThee4=.a409a8df-4f9e-4378-bb0d-820c3ee6016b@github.com> Message-ID: On Fri, 28 May 2021 19:40:00 GMT, Daniel D. Daugherty wrote: > A trivial fix to cleanup Threads_lock comments in JVM/TI function headers. > > Also remove errant text added by the jframeID XSL template code: > > > // java_thread - unchecked > // depth - pre-checked as non-negative > > > The first line about `jthread` is output in error. > Only the second line about `depth` should be included. > > This fix is tested with a Mach5 Tier1 job set. This pull request has now been integrated. Changeset: 40e4171f Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/40e4171f562da2f6a507efc7ad359e298199ed71 Stats: 91 lines in 3 files changed: 0 ins; 52 del; 39 mod 8264800: cleanup Threads_lock comments in JVM/TI function headers Reviewed-by: coleenp, rehn, dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/4254 From dcubed at openjdk.java.net Tue Jun 1 20:52:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 1 Jun 2021 20:52:40 GMT Subject: RFR: 8266130: convert Thread-SMR stress tests from counter based to time based [v2] In-Reply-To: References: Message-ID: > The Thread-SMR project added counter based tests for various APIs. > See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes". > > Time based tests are more appropriate for stress kits so I'm > updating the counter based tests to be time based instead. > > Two of the updated tests have shaken out failures that are tracked by: > > JDK-8264605 vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" > > JDK-8266593 vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" > > These updated tests are tested via Mach5 Tier[134567]. > They have also been test by my Stress Kit runs for jdk-17+2[0-4]. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Apply @plummercj code review fix from JDK-8265153 to this review also. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4237/files - new: https://git.openjdk.java.net/jdk/pull/4237/files/8ec5caed..2ab79a2c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4237&range=00-01 Stats: 23 lines in 11 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/4237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4237/head:pull/4237 PR: https://git.openjdk.java.net/jdk/pull/4237 From cjplummer at openjdk.java.net Tue Jun 1 21:01:29 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Jun 2021 21:01:29 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: References: Message-ID: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com> On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov wrote: > nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). > This makes possible failure when debuggee tries to connect before debugger starts listening. > The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. > Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. > > Couple details about the fix: > - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; > - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. > > Testing: all tests which use IOPipe/SocketIOPipe classes: > - test/hotspot/jtreg/serviceability/dcmd/framework > - test/hotspot/jtreg/vmTestbase/nsk/jdi > - test/hotspot/jtreg/vmTestbase/nsk/jdwp test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51: > 49: String cmd = pipe.readln(); > 50: int exitCode = PASSED; > 51: if ("quit".equals(cmd)) { I don't see how this is an improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/4235 From lmesnik at openjdk.java.net Tue Jun 1 22:04:52 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 1 Jun 2021 22:04:52 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly Message-ID: 8266337: ThreadTimesClosure doesn't handle exceptions properly ------------- Commit messages: - 8266337: ThreadTimesClosure doesn't handle exceptions properly Changes: https://git.openjdk.java.net/jdk/pull/4292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266337 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4292/head:pull/4292 PR: https://git.openjdk.java.net/jdk/pull/4292 From amenkov at openjdk.java.net Tue Jun 1 22:28:28 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 1 Jun 2021 22:28:28 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com> References: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com> Message-ID: On Tue, 1 Jun 2021 17:56:10 GMT, Chris Plummer wrote: >> nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). >> This makes possible failure when debuggee tries to connect before debugger starts listening. >> The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. >> Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. >> >> Couple details about the fix: >> - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; >> - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. >> >> Testing: all tests which use IOPipe/SocketIOPipe classes: >> - test/hotspot/jtreg/serviceability/dcmd/framework >> - test/hotspot/jtreg/vmTestbase/nsk/jdi >> - test/hotspot/jtreg/vmTestbase/nsk/jdwp > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51: > >> 49: String cmd = pipe.readln(); >> 50: int exitCode = PASSED; >> 51: if ("quit".equals(cmd)) { > > I don't see how this is an improvement. Working on the fix I got null cmd here. I think "Invalid command received null" failure is clearer than NPE ------------- PR: https://git.openjdk.java.net/jdk/pull/4235 From ysuenaga at openjdk.java.net Tue Jun 1 22:42:28 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 1 Jun 2021 22:42:28 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 17:51:24 GMT, Chris Plummer wrote: >> Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). >> >> * serviceability/sa/ClhsdbDumpheap.java >> * serviceability/sa/ClhsdbFindPC.java >> * serviceability/sa/ClhsdbInspect.java >> * serviceability/sa/ClhsdbSymbol.java >> * serviceability/sa/TestHeapDumpForInvokeDynamic.java >> * serviceability/sa/TestJmapCore.java >> * serviceability/sa/TestJmapCoreMetaspace.java >> >> They need to handle relocated objects and/or live regions (pages). SA should handle them. >> >> This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help? > > Marked as reviewed by cjplummer (Reviewer). Thanks @plummercj for the review! May I get the review from ZGC folks? ------------- PR: https://git.openjdk.java.net/jdk/pull/4057 From dholmes at openjdk.java.net Tue Jun 1 22:46:29 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Jun 2021 22:46:29 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly In-Reply-To: References: Message-ID: <_dj-ctWdVqcFmAgThgQzG-YTnj875WRe8N0gVo1oSGI=.c743c8f8-f6f0-403d-adab-2605adac1012@github.com> On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Hi Leonid, This change looks good to me. Thanks, David src/hotspot/share/services/management.cpp line 1708: > 1706: Threads::threads_do(&ttc); > 1707: } > 1708: ttc.do_unlocked(THREAD); At first I thought this should use CHECK_0 not THREAD so it will return zero when an exception occurs. But this goes straight back to Java code so the exception will propagate and the return value can't be examined. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4292 From sspitsyn at openjdk.java.net Tue Jun 1 23:12:31 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 1 Jun 2021 23:12:31 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Hi Leonid, This looks good to me. One thing to consider is to use `os::strdup_check_oom` instead of `os::strdup`. The os::strdup can return NULL. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4292 From lmesnik at openjdk.java.net Wed Jun 2 01:20:48 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:20:48 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2] In-Reply-To: References: Message-ID: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: strdup_check_oom is used instead of strdup. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4292/files - new: https://git.openjdk.java.net/jdk/pull/4292/files/e1542ddb..15572433 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4292&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4292/head:pull/4292 PR: https://git.openjdk.java.net/jdk/pull/4292 From lmesnik at openjdk.java.net Wed Jun 2 01:20:48 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:20:48 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly Serguei, Thanks for the suggestion. It is not exactly part of this bug but is really close. Updated to used strdup_check_oom instead of strdup. ------------- PR: https://git.openjdk.java.net/jdk/pull/4292 From coleenp at openjdk.java.net Wed Jun 2 02:01:30 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Jun 2021 02:01:30 GMT Subject: RFR: 8266967: debug.cpp utility find() should print Java Object fields. [v2] In-Reply-To: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com> References: <3q3pcFTsL_lG-lh78-zZSkTomOw0vPLLAoPm6ez-TAM=.45e3cf48-009b-4899-ac3d-851338987959@github.com> Message-ID: On Thu, 13 May 2021 13:24:17 GMT, Kevin Walls wrote: >> This change enables debug.cpp's find() utility to print Java Objects with their fields. >> >> find() calls os::print_location, and Java heap objects are printed with instanceKlass oop_print_on. >> Removing the ifdef for defining oop_print_on for instanceKlass, and also on methods in FieldPrinter and FieldDescriptor, make this work. >> >> >> Checking other uses of os::print_location this might affect: >> >> macroAssembler_x86.cpp has MacroAssembler::print_state32 and MacroAssembler::print_state64 >> which use os::print_location to print register contents and print words at top of stack. >> These will be more verbose, as it already is in non-PRODUCT builds. >> >> vmError uses os::print_location when showing the stack, i.e. this output: >> >> Stack slot to memory mapping: >> stack at sp + 0 slots: 0x0000000000000002 is an unknown value >> ..etc... >> >> ...will be more verbose when Java object references are found (for the 8 stack slots it tries to show). >> >> >> Shenandoah uses os::print_location once, but for non-Java heap objects so nothing changes. >> >> >> Manual testing on Linux-x64 and Windows: old behaviour shows these two lines only: >> >> "Executing find" >> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader >> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader' >> >> ...then with the change the full info: >> >> "Executing find" >> 0x00000000ff0a03e0 is an oop: jdk.internal.loader.ClassLoaders$AppClassLoader >> {0x00000000ff0a03e0} - klass: 'jdk/internal/loader/ClassLoaders$AppClassLoader' >> - ---- fields (total size 13 words): >> - private 'defaultAssertionStatus' 'Z' @12 false >> - private final 'parent' 'Ljava/lang/ClassLoader;' @24 a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000000ff0a0a >> 40} (ff0a0a40) >> - private final 'name' 'Ljava/lang/String;' @28 "app"{0x00000000ff0d0060} (ff0d0060) >> - private final 'unnamedModule' 'Ljava/lang/Module;' @32 a 'java/lang/Module'{0x00000000ff0a0448} (ff0a0448) >> ...etc... > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > ifdef correction This looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4011 From cjplummer at openjdk.java.net Wed Jun 2 07:05:31 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 2 Jun 2021 07:05:31 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 22:39:28 GMT, Yasumasa Suenaga wrote: > May I get the review from ZGC folks? The ZGC team won't be doing SA code reviews. I'll have someone else from the svc team do a second review, but keep in mind these reviews are primarily just to make sure the changes won't break anything (other than SA support for ZGC). ------------- PR: https://git.openjdk.java.net/jdk/pull/4057 From alanb at openjdk.java.net Wed Jun 2 08:47:32 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Jun 2021 08:47:32 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest I think the named pipe scenario needs more discussion. For the more simpler case of overwriting an existing file then opt-in in with an option like `-overwrite` might be clearer than `-rewrite`. It's important that we choose the right name because there are several commands that may need to do the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 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: 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: 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: On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf 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:32:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Jun 2021 10:32:41 GMT Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes Message-ID: Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). Affected tests: - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. Testing: - local testing of affected test areas - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). Thanks, David ------------- Commit messages: - 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes Changes: https://git.openjdk.java.net/jdk/pull/4302/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4302&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268094 Stats: 339 lines in 14 files changed: 0 ins; 326 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4302/head:pull/4302 PR: https://git.openjdk.java.net/jdk/pull/4302 From vlivanov at openjdk.java.net Wed Jun 2 10:32:41 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Jun 2021 10:32:41 GMT Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes wrote: > Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). > > Affected tests: > > - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ > > This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. > > Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. > > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java > > These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. > > Testing: > - local testing of affected test areas > - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). > > Thanks, > David Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4302 From dholmes at openjdk.java.net Wed Jun 2 10:32:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Jun 2021 10:32:41 GMT Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 10:25:38 GMT, Vladimir Ivanov wrote: >> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). >> >> Affected tests: >> >> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ >> >> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. >> >> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. >> >> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java >> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java >> >> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. >> >> Testing: >> - local testing of affected test areas >> - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). >> >> Thanks, >> David > > Looks good. Thanks @iwanowww ! ------------- PR: https://git.openjdk.java.net/jdk/pull/4302 From rehn at openjdk.java.net Wed Jun 2 10:39:29 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 2 Jun 2021 10:39:29 GMT Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes wrote: > Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). > > Affected tests: > > - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ > > This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. > > Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. > > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java > > These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. > > Testing: > - local testing of affected test areas > - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). > > Thanks, > David Seems good! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4302 From david.holmes at oracle.com Wed Jun 2 10:45:22 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jun 2021 20:45:22 +1000 Subject: RFR: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes In-Reply-To: References: Message-ID: On 2/06/2021 8:39 pm, Robbin Ehn wrote: > On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes wrote: > >> Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). >> >> Affected tests: >> >> - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ >> >> This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. >> >> Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. >> >> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java >> - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java >> >> These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. >> >> Testing: >> - local testing of affected test areas >> - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). >> >> Thanks, >> David > > Seems good! Thanks Robbin! David > ------------- > > Marked as reviewed by rehn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4302 > 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: 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 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: 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: > 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: 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: 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. > > 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 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 Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang 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:39 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Wed, 2 Jun 2021 12:02:39 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang wrote: >> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > one more change 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/4172 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: 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 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: 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: On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf 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: 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 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 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 dholmes at openjdk.java.net Wed Jun 2 12:27:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Jun 2021 12:27:31 GMT Subject: Integrated: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 10:08:02 GMT, David Holmes wrote: > Part of the JEP-306 integration wasn't tested past tier 3 and missed some changes needed in the vmTestbase/nsk tests. The crux of the changes for JEP-306 are that the strictfp modifier has no affect any more (all fp math is strict) and is not observable as a modifier. At the VM level ACC_STRICT is no longer defined for classfiles version 61+ (ie JDK 17+). > > Affected tests: > > - vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/ > > This test has a part that expects to read the ACC_STRICT modifier for a strictfp method - so that part is just deleted. > > Other jvmti test files refer to ACC_STRICT (but don't test anything) and so those references are also deleted. > > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses007.java > - vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses008.java > > These each have two subtests (07 and 08) that test changing the strictfp modifier on a method. These subtests are just deleted. > > Testing: > - local testing of affected test areas > - tiers 1-5 also submitted for good measure (but may take a while to run and should not delay getting these fixes in places so that the CI returns to normal - thanks). > > Thanks, > David This pull request has now been integrated. Changeset: dc19baca Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/dc19baca3363a105a5cc1dbc02cbe3ea65e1209e Stats: 339 lines in 14 files changed: 0 ins; 326 del; 13 mod 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes Reviewed-by: vlivanov, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/4302 From rschmelter at openjdk.java.net Wed Jun 2 14:04:31 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Wed, 2 Jun 2021 14:04:31 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Extend HeapDumpTest I would rename the option to `-overwrite`, since it has a clear meaning (to replace the old content with new one). And to really implement the overwrite semantics, the file should be opened with `O_TRUNC`. Currently `-rewrite` just replaces the start of an already existing file with a the heap dump. If the original file was larger than the heap dump, we have trailing bytes, which would lead to errors when tools try to parse the dump. And on Unix it might be a good idea to use O_NOCTTY, so we don't accidentally assign a controlling tty when dumping to a console ('ve never seen actual problems omitting this, but it seems safe to add it). Even with this changes you can still write to a fifo/tty on Unix or a named pipe on Windows, since O_TRUNC is ignored for these types of files. And since you already created a CSR, I would propose to close [JDK-8263066](https://bugs.openjdk.java.net/browse/JDK-8263066) and instead try to get this into the mainline. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 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: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v4] 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 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:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:49 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v3] In-Reply-To: References: Message-ID: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8267543: Post JEP 411 refactoring: security ------------- Changes: https://git.openjdk.java.net/jdk/pull/4172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=02 Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/4172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172 PR: https://git.openjdk.java.net/jdk/pull/4172 From weijun at openjdk.java.net 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: Integrated: 8267521: Post JEP 411 refactoring: maximum covering > 50K In-Reply-To: References: Message-ID: On Fri, 21 May 2021 01:52:27 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. This pull request has now been integrated. Changeset: 508cec75 Author: Weijun Wang 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 weijun at openjdk.java.net Wed Jun 2 15:51:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:49 GMT Subject: Integrated: 8267543: Post JEP 411 refactoring: security In-Reply-To: References: Message-ID: On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang wrote: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. > > I'll add a copyright year update commit before integration. This pull request has now been integrated. Changeset: 40d23a0c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/40d23a0c0b955ae4636800be183da7a71665f79f Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod 8267543: Post JEP 411 refactoring: security Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From akozlov at openjdk.java.net Wed Jun 2 20:05:56 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Jun 2021 20:05:56 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v3] In-Reply-To: References: Message-ID: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: - Fix create_binary_file - Rename option to -overwrite ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4183/files - new: https://git.openjdk.java.net/jdk/pull/4183/files/7faa6900..8b97a1e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=01-02 Stats: 26 lines in 11 files changed: 0 ins; 8 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183 PR: https://git.openjdk.java.net/jdk/pull/4183 From akozlov at openjdk.java.net Wed Jun 2 20:51:46 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Jun 2021 20:51:46 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:05:56 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision: > > - Fix create_binary_file > - Rename option to -overwrite I have renamed the option to `-overwrite`. Nice catch about missing O_TRUNC, thanks! A case for the missing O_NOCTTY looks rather special, wouldn't it be a configuration issue?.. SInce JDK-8263066 suggests more enhancements, it may be worth keeping it to track the remaining ones. @AlanBateman The patch does not do anything special to the named pipe use-case, although makes it possible. Do you suggest removing mentions of the use-case from the CSR? Otherwise, what concerns could I address? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From akozlov at openjdk.java.net Wed Jun 2 20:57:02 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Jun 2021 20:57:02 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v4] In-Reply-To: References: Message-ID: > Please review a small change that adds an option to GC.heap_dump to use an existing file. > > The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. > > Reviews of the CSR linked to the bug would be appreciated as well. Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix windows flags (although complied fine) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4183/files - new: https://git.openjdk.java.net/jdk/pull/4183/files/8b97a1e4..7f19663b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4183&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4183/head:pull/4183 PR: https://git.openjdk.java.net/jdk/pull/4183 From sspitsyn at openjdk.java.net Wed Jun 2 21:14:39 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Jun 2021 21:14:39 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2] In-Reply-To: References: Message-ID: <9iwnQuvgxYP1nJz25GoQDrX-WiNF8BjZwbDJplox470=.1c9e54e7-99f8-4a3e-b470-4c076be1a369@github.com> On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik wrote: >> 8266337: ThreadTimesClosure doesn't handle exceptions properly > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > strdup_check_oom is used instead of strdup. Leonid, I'm not convinced yet it is okay to call strdup_check_oom in this management function. It'd be nice to check if David agreed with this update. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/4292 From sspitsyn at openjdk.java.net Wed Jun 2 21:59:40 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Jun 2021 21:59:40 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik wrote: >> 8266337: ThreadTimesClosure doesn't handle exceptions properly > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > strdup_check_oom is used instead of strdup. Leonid, After some thinking, I'm okay with the update. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4292 From lmesnik at openjdk.java.net Wed Jun 2 21:59:42 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 21:59:42 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik wrote: >> 8266337: ThreadTimesClosure doesn't handle exceptions properly > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > strdup_check_oom is used instead of strdup. I believe that it is safer to use strdup_check_oom anywhere except error handling. The plain strdup might cause delayed SEGV hard to diagnose. Might be it makes sense to file another RFE to review strdup usage. ------------- PR: https://git.openjdk.java.net/jdk/pull/4292 From dholmes at openjdk.java.net Thu Jun 3 00:45:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 3 Jun 2021 00:45:36 GMT Subject: RFR: 8266337: ThreadTimesClosure doesn't handle exceptions properly [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:20:48 GMT, Leonid Mesnik wrote: >> 8266337: ThreadTimesClosure doesn't handle exceptions properly > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > strdup_check_oom is used instead of strdup. I don't think there is any practical difference between strdup and strdup_check_oom - the chances that we exhaust the C heap just as we hit this call are extremely low, and no matter what we do here the VM is dying if that happens (we may not even have enough memory to call vm_exit_out_of_memory!). The use of strdup_check_oom is at least cleaner as we don't have any issues with not checking the return value from strdup if a static checker looks at this code. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4292 From lmesnik at openjdk.java.net Thu Jun 3 04:15:39 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 04:15:39 GMT Subject: Integrated: 8266337: ThreadTimesClosure doesn't handle exceptions properly In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 21:54:27 GMT, Leonid Mesnik wrote: > 8266337: ThreadTimesClosure doesn't handle exceptions properly This pull request has now been integrated. Changeset: 06f87cf4 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/06f87cf4419be9c1bffe996d5d476d30b0f86bf6 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod 8266337: ThreadTimesClosure doesn't handle exceptions properly Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/4292 From lmesnik at openjdk.java.net Thu Jun 3 06:22:53 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 06:22:53 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash Message-ID: Fixed a race condition between posting and enabling DynamicCodeGenerated event. ------------- Commit messages: - 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash Changes: https://git.openjdk.java.net/jdk/pull/4331/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4331&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212155 Stats: 122 lines in 3 files changed: 116 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4331/head:pull/4331 PR: https://git.openjdk.java.net/jdk/pull/4331 From rschmelter at openjdk.java.net Thu Jun 3 13:32:36 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Thu, 3 Jun 2021 13:32:36 GMT Subject: RFR: 8267666: Add option to jcmd GC.heap_dump to use existing file [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov wrote: >> Please review a small change that adds an option to GC.heap_dump to use an existing file. >> >> The option is necessary if the target file is a predefined file-like object, like a named pipe. This opens up a lot of possibilities to process a heap dump without storing it to the file system first. >> >> Reviews of the CSR linked to the bug would be appreciated as well. > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix windows flags (although complied fine) Yeah, I tjhink the O_NOCTTY is more a theoretical consideration. I've never seen problems in practice. ------------- PR: https://git.openjdk.java.net/jdk/pull/4183 From sspitsyn at openjdk.java.net Thu Jun 3 16:53:38 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 3 Jun 2021 16:53:38 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash In-Reply-To: References: Message-ID: <-6_SJRedB1131iS7_XYwro6x3ANkwoGyo_oG9pDftKA=.3658fe2f-66a3-4424-a679-5d75ce2182d3@github.com> On Thu, 3 Jun 2021 06:15:28 GMT, Leonid Mesnik wrote: > Fixed a race condition between posting and enabling DynamicCodeGenerated event. Hi Leonid, The fix looks good to me. Thanks, Serguei src/hotspot/share/prims/jvmtiExport.cpp line 2293: > 2291: // jvmti thread state. > 2292: // The collector and/or state might be NULL if JvmtiDynamicCodeEventCollector has been initialized > 2293: // while JVMTI_EVENT_DYNAMIC_CODE_GENERATED was disabled Could you, reballance this comment a little bit and add a dot at the end? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4331 From lmesnik at openjdk.java.net Thu Jun 3 17:24:07 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 17:24:07 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: > Fixed a race condition between posting and enabling DynamicCodeGenerated event. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4331/files - new: https://git.openjdk.java.net/jdk/pull/4331/files/4a998eeb..c650f446 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4331&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4331&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4331/head:pull/4331 PR: https://git.openjdk.java.net/jdk/pull/4331 From sspitsyn at openjdk.java.net Thu Jun 3 19:33:05 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 3 Jun 2021 19:33:05 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik wrote: >> Fixed a race condition between posting and enabling DynamicCodeGenerated event. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed comment Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4331 From cjplummer at openjdk.java.net Thu Jun 3 20:34:55 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 3 Jun 2021 20:34:55 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: References: Message-ID: <17kf5_XVWb5zKNMjojZW4H0Eyjdscj6qqwse8WkCs9k=.cfd1d58f-85b1-434b-adb4-240942b3276c@github.com> On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov wrote: > nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). > This makes possible failure when debuggee tries to connect before debugger starts listening. > The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. > Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. > > Couple details about the fix: > - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; > - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. > > Testing: all tests which use IOPipe/SocketIOPipe classes: > - test/hotspot/jtreg/serviceability/dcmd/framework > - test/hotspot/jtreg/vmTestbase/nsk/jdi > - test/hotspot/jtreg/vmTestbase/nsk/jdwp Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4235 From cjplummer at openjdk.java.net Thu Jun 3 20:34:56 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 3 Jun 2021 20:34:56 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: References: <7FgAnGdpSMqyEYLfFy1TWPVjajLKa-BAULbz5RZbHKs=.b049dfbe-263c-4f16-9aae-94adf15794b9@github.com> Message-ID: <-D9Ddd75nkNEiNOdzirhrO1InHmFjnZd6zUSZJsGCbc=.052b3d29-0daf-4b34-bdc4-ec218e324420@github.com> On Tue, 1 Jun 2021 22:24:31 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java line 51: >> >>> 49: String cmd = pipe.readln(); >>> 50: int exitCode = PASSED; >>> 51: if ("quit".equals(cmd)) { >> >> I don't see how this is an improvement. > > Working on the fix I got null cmd here. > I think "Invalid command received null" failure is clearer than NPE Ok ------------- PR: https://git.openjdk.java.net/jdk/pull/4235 From dcubed at openjdk.java.net Thu Jun 3 21:19:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 3 Jun 2021 21:19:59 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik wrote: >> Fixed a race condition between posting and enabling DynamicCodeGenerated event. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed comment Thumbs up. I just have minor comments. Just curious: what's the execution times for the new test on the Mach5 platforms? test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 27: > 25: #include > 26: > 27: jvmtiEnv* jvmti; Should this be 'static'? test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 35: > 33: JNIEXPORT > 34: void JNICALL Java_DynamicCodeGeneratedTest_changeEventNotificationMode(JNIEnv* jni, jclass cls) { > 35: while(true) { nit - please add space before '(' ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4331 From dcubed at openjdk.java.net Thu Jun 3 21:24:57 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 3 Jun 2021 21:24:57 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik wrote: >> Fixed a race condition between posting and enabling DynamicCodeGenerated event. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed comment test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55: > 53: Reference.reachabilityFence(result); > 54: }).start(); > 55: } I just noticed no `join()` calls to clean up these threads. Does this mean we'll have 10,000 thread objects waiting around until the end of the program? ------------- PR: https://git.openjdk.java.net/jdk/pull/4331 From lmesnik at openjdk.java.net Thu Jun 3 21:33:29 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 21:33:29 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v3] In-Reply-To: References: Message-ID: > Fixed a race condition between posting and enabling DynamicCodeGenerated event. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4331/files - new: https://git.openjdk.java.net/jdk/pull/4331/files/c650f446..7482d580 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4331&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4331&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4331.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4331/head:pull/4331 PR: https://git.openjdk.java.net/jdk/pull/4331 From sspitsyn at openjdk.java.net Thu Jun 3 21:47:58 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 3 Jun 2021 21:47:58 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: References: Message-ID: On Thu, 27 May 2021 23:00:56 GMT, Alex Menkov wrote: > nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). > This makes possible failure when debuggee tries to connect before debugger starts listening. > The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. > Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. > > Couple details about the fix: > - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; > - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. > > Testing: all tests which use IOPipe/SocketIOPipe classes: > - test/hotspot/jtreg/serviceability/dcmd/framework > - test/hotspot/jtreg/vmTestbase/nsk/jdi > - test/hotspot/jtreg/vmTestbase/nsk/jdwp Hi Alex, This is nice refactoring. It looks good to me. The fix has a potential to introduce new regressions. I hope you run all the impacted tests on all platforms. Thanks, Serguei test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 275: > 273: if (listening) { > 274: // listenerThread == null means the test is not updated yet > 275: // to start IOPipe listening before launching debuggee. I like this workaround for non-updated tests. This spot can be simplified after all tests got updated. test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 279: > 277: // start listening and accept connection on the current thread > 278: listenerThread = new ListenerThread(); > 279: listenerThread.run(); It is not clear, why `listenerThread.run()` is used instead of `listenerThread.start()` as at the line 257. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4235 From dcubed at openjdk.java.net Thu Jun 3 21:57:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 3 Jun 2021 21:57:55 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:33:29 GMT, Leonid Mesnik wrote: >> Fixed a race condition between posting and enabling DynamicCodeGenerated event. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated test. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4331 From lmesnik at openjdk.java.net Thu Jun 3 22:26:58 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 22:26:58 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v3] In-Reply-To: References: Message-ID: <-7O2hk6F8PtOxkmPc2vO6pp5qIrhi9MzY42vAJCirrQ=.19624775-87f9-453c-92cd-8096aff3dd8d@github.com> On Thu, 3 Jun 2021 21:33:29 GMT, Leonid Mesnik wrote: >> Fixed a race condition between posting and enabling DynamicCodeGenerated event. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated test. > Just curious: what's the execution times for the new test on the Mach5 platforms? It takes ~3 seconds to complete the test in Mach5. ------------- PR: https://git.openjdk.java.net/jdk/pull/4331 From lmesnik at openjdk.java.net Thu Jun 3 22:26:59 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 3 Jun 2021 22:26:59 GMT Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:21:45 GMT, Daniel D. Daugherty wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed comment > > test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55: > >> 53: Reference.reachabilityFence(result); >> 54: }).start(); >> 55: } > > I just noticed no `join()` calls to clean up these threads. > Does this mean we'll have 10,000 thread objects waiting around > until the end of the program? Yes, we don't care about thread completion. Just start new threads while the first ones are completed. I reduced the number of threads to 2000. It is still enough to reproduce the crash. However, 2,000 thread doesn't harm any system. I checked in Mach5. ------------- PR: https://git.openjdk.java.net/jdk/pull/4331 From amenkov at openjdk.java.net Thu Jun 3 22:45:00 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 3 Jun 2021 22:45:00 GMT Subject: RFR: 8237388: serviceability/dcmd/framework/VMVersionTest.java fails with connection refused error. In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:44:32 GMT, Serguei Spitsyn wrote: >> nsk test framework for testing jdi/jdwp assumes that the test launch debuggee first and then creates IOPipe to communicate with debuggee (debugger listens, debugee connects to the IOPipe socket). >> This makes possible failure when debuggee tries to connect before debugger starts listening. >> The fix changes logic of the tests to start listening on IOPipe socket before launch debuggee. >> Other tests which use IOPipe/SocketIOPipe and have the same issue (there are a lot of them) will be fixes as separate issues. >> >> Couple details about the fix: >> - debugee.getPipeServerSocket() just calls binder.getPipeServerSocket(), returned ServerSocket can be changed only by DebugeeBinder.prepareForPipeConnection which is called by some tests; >> - connectingProcess logic is broken. The only place it's used is BasicSocketConnection.checkConnectingProcess, which is called from SocketConnection.continueAttach. But continueAttach is called from debuggee code (listening == false) while connectingProcess is set only from debugger code (listening == true). So it didn't work and I dropped it. >> >> Testing: all tests which use IOPipe/SocketIOPipe classes: >> - test/hotspot/jtreg/serviceability/dcmd/framework >> - test/hotspot/jtreg/vmTestbase/nsk/jdi >> - test/hotspot/jtreg/vmTestbase/nsk/jdwp > > test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 275: > >> 273: if (listening) { >> 274: // listenerThread == null means the test is not updated yet >> 275: // to start IOPipe listening before launching debuggee. > > I like this workaround for non-updated tests. This spot can be simplified after all tests got updated. Yes, the plan is to put assert here later. > test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java line 279: > >> 277: // start listening and accept connection on the current thread >> 278: listenerThread = new ListenerThread(); >> 279: listenerThread.run(); > > It is not clear, why `listenerThread.run()` is used instead of `listenerThread.start()` as at the line 257. This is part of the workaround for non-updated tests - the tests should work the same way they did. start() would start new thread, so listening starts a bit later and we have more chances to get "connection refused" error. ------------- PR: https://git.openjdk.java.net/jdk/pull/4235 From sspitsyn at openjdk.java.net Fri Jun 4 01:42:55 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 4 Jun 2021 01:42:55 GMT Subject: RFR: 8266957: SA has not followed JDK-8220587 and JDK-8224965 In-Reply-To: References: Message-ID: <1BX_mRpzZBqOhj_B9a1c4Vd90ZbktO__FWmjSqGTL-M=.4a1e3e49-14b9-465b-8d1f-38c6c7e5f986@github.com> On Mon, 17 May 2021 12:07:13 GMT, Yasumasa Suenaga wrote: > Following jtreg tests for SA would fail because SA has not followed [JDK-8220587](https://bugs.openjdk.java.net/browse/JDK-8220587) and [JDK-8224965](https://bugs.openjdk.java.net/browse/JDK-8224965). > > * serviceability/sa/ClhsdbDumpheap.java > * serviceability/sa/ClhsdbFindPC.java > * serviceability/sa/ClhsdbInspect.java > * serviceability/sa/ClhsdbSymbol.java > * serviceability/sa/TestHeapDumpForInvokeDynamic.java > * serviceability/sa/TestJmapCore.java > * serviceability/sa/TestJmapCoreMetaspace.java > > They need to handle relocated objects and/or live regions (pages). SA should handle them. > > This change passes serviceability/sa jtreg tests on Linux x64 with -vmoption:-XX:+UseZGC, but I want to know this change works fine on testbed for ZGC in Oracle. Could you help? Hi Yasumasa, This looks okay to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4057 From david.holmes at oracle.com Fri Jun 4 02:21:10 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Jun 2021 12:21:10 +1000 Subject: RFR: 8212155: Race condition when posting dynamic_code_generated event leads to JVM crash [v2] In-Reply-To: References: Message-ID: Hi Dan, On 4/06/2021 7:24 am, Daniel D.Daugherty wrote: > On Thu, 3 Jun 2021 17:24:07 GMT, Leonid Mesnik wrote: > >>> Fixed a race condition between posting and enabling DynamicCodeGenerated event. >> >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed comment > > test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/DynamicCodeGeneratedTest.java line 55: > >> 53: Reference.reachabilityFence(result); >> 54: }).start(); >> 55: } > > I just noticed no `join()` calls to clean up these threads. Java doesn't need a join() to "cleanup threads". The main reason to join() threads in a test is to ensure they have terminated before we hand control back to jtreg; and if not daemons to ensure we terminate more predictably. Cheers, David ----- > Does this mean we'll have 10,000 thread objects waiting around > until the end of the program? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4331 > From cjplummer at openjdk.java.net Fri Jun 4 03:44:04 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 4 Jun 2021 03:44:04 GMT Subject: RFR: 8263323: Debug Agent help output includes invalid URL Message-ID: Rather than embed a URL in the help output, which needs to be updated if the location of docs ever changes, just include a description of the document so it can be looked up. The output now looks like: $ ./java -agentlib:jdwp=help Java Debugger JDWP Agent Library -------------------------------- (See the "Oracle VM Invocation Options" section of the JPDA "Connection and Invocation Details" document for more information.) jdwp usage: java -agentlib:jdwp=[help]|[