From ysuenaga at openjdk.java.net Wed Apr 6 00:48:00 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 6 Apr 2022 00:48:00 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container Message-ID: jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 / # / # stat /tmp File: /tmp Size: 29 Blocks: 0 IO Block: 4096 directory Device: efh/239d Inode: 135674931 Links: 1 Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-04-05 08:51:37.000000000 Modify: 2022-04-05 08:51:37.000000000 Change: 2022-04-05 08:51:37.000000000 / # stat /proc/1/root/tmp File: /proc/1/root/tmp Size: 29 Blocks: 0 IO Block: 4096 directory Device: e1h/225d Inode: 135674931 Links: 1 Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2022-04-05 08:51:37.000000000 Modify: 2022-04-05 08:50:42.000000000 Change: 2022-04-05 08:50:42.000000000 ------------- Commit messages: - 8284330: jcmd may not be able to find processes in the container Changes: https://git.openjdk.java.net/jdk/pull/8103/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8103&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284330 Stats: 42 lines in 1 file changed: 27 ins; 10 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8103/head:pull/8103 PR: https://git.openjdk.java.net/jdk/pull/8103 From kevinw at openjdk.java.net Wed Apr 6 09:53:41 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 6 Apr 2022 09:53:41 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. (adding a note to trigger email notification, as that appears lost...) ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From djelinski at openjdk.java.net Wed Apr 6 12:14:11 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 12:14:11 GMT Subject: RFR: 8284444: Sting typo Message-ID: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> This patch adds missing `r` in `string`s ------------- Commit messages: - Fix sting typo Changes: https://git.openjdk.java.net/jdk/pull/8125/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284444 Stats: 25 lines in 8 files changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8125.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125 PR: https://git.openjdk.java.net/jdk/pull/8125 From kevinw at openjdk.java.net Wed Apr 6 12:22:47 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 6 Apr 2022 12:22:47 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 09:04:56 GMT, Yasumasa Suenaga wrote: > jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. > > For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. > > > $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 > / # > / # stat /tmp > File: /tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: efh/239d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:51:37.000000000 > Change: 2022-04-05 08:51:37.000000000 > > / # stat /proc/1/root/tmp > File: /proc/1/root/tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: e1h/225d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:50:42.000000000 > Change: 2022-04-05 08:50:42.000000000 Hi, So it's that the /tmp inode can be the same, between the host and a container. You might like some text for the bug description as that could be clearer: ----------- jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan for all temporary directories: the host temp dir, and (through the /proc filesystem) the temp dirs of running containers. It checks the inode value to ensure a temp directory under /proc is not the same as the host temp directory. However the inode can have the same value in the container and host. Thus we should check device id additionally. ----------- I think the changes look good. VM's temp directory (from os::get_temp_directory()) is a constant, i.e. /tmp, in current implementations, so keeping the inode looks safe. Just being picky with the English, "isSameWithTemporaryDirectory" is odd (we would say something is "the same as" rather than "with"). It could be called "tempDirectoryEquals" ? 8-) Maybe the comment could also be clearer: 116 * Host and container devices could have the same inode value, 117 * so we also need to check the device id. ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From kcr at openjdk.java.net Wed Apr 6 12:26:40 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 12:26:40 GMT Subject: RFR: 8284444: Sting typo In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski wrote: > This patch adds missing `r` in `string`s This PR cuts across many areas, so will need multiple reviewers. Regarding the LCMS file, we typically don't make these kind of changes in third-party code, since it will cause our code to diverge from the upstream code, which can lead to merge conflicts down the road. @prrace will need to approve this or else you will need to revert that file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From ysuenaga at openjdk.java.net Wed Apr 6 12:44:35 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 6 Apr 2022 12:44:35 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v2] In-Reply-To: References: Message-ID: > jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. > > For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. > > > $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 > / # > / # stat /tmp > File: /tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: efh/239d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:51:37.000000000 > Change: 2022-04-05 08:51:37.000000000 > > / # stat /proc/1/root/tmp > File: /proc/1/root/tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: e1h/225d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:50:42.000000000 > Change: 2022-04-05 08:50:42.000000000 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8103/files - new: https://git.openjdk.java.net/jdk/pull/8103/files/e5f76a60..0e0ccbe0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8103&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8103&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8103/head:pull/8103 PR: https://git.openjdk.java.net/jdk/pull/8103 From ysuenaga at openjdk.java.net Wed Apr 6 12:44:36 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 6 Apr 2022 12:44:36 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 12:19:32 GMT, Kevin Walls wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Hi, > So it's that the /tmp inode can be the same, between the host and a container. > You might like some text for the bug description as that could be clearer: > ----------- > > jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan for all temporary directories: the host temp dir, and (through the /proc filesystem) the temp dirs of running containers. > > It checks the inode value to ensure a temp directory under /proc is not the same as the host temp directory. > However the inode can have the same value in the container and host. Thus we should check device id additionally. > > ----------- > > I think the changes look good. > > VM's temp directory (from os::get_temp_directory()) is a constant, i.e. /tmp, in current implementations, so keeping the inode looks safe. > > Just being picky with the English, "isSameWithTemporaryDirectory" is odd (we would say something is "the same as" rather than "with"). > It could be called "tempDirectoryEquals" ? 8-) > > Maybe the comment could also be clearer: > > 116 * Host and container devices could have the same inode value, > 117 * so we also need to check the device id. @kevinjwalls Thanks for your comment! I updated JBS and this PR. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From kevinw at openjdk.java.net Wed Apr 6 13:22:41 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 6 Apr 2022 13:22:41 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 12:44:35 GMT, Yasumasa Suenaga wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Marked as reviewed by kevinw (Committer). Great, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From aivanov at openjdk.java.net Wed Apr 6 13:42:41 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 6 Apr 2022 13:42:41 GMT Subject: RFR: 8284444: Sting typo In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski wrote: > This patch adds missing `r` in `string`s src/java.desktop/share/native/liblcms/cmstypes.c line 3668: > 3666: // Auxiliary, read an string specified as count + string > 3667: static > 3668: cmsBool ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section) As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63: > 61: message.creating-association-with-null-extension=Creating association with null extension. > 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required. > 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build . I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From djelinski at openjdk.java.net Wed Apr 6 14:08:39 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 14:08:39 GMT Subject: RFR: 8284444: Sting typo In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 13:38:03 GMT, Alexey Ivanov wrote: >> This patch adds missing `r` in `string`s > > src/java.desktop/share/native/liblcms/cmstypes.c line 3668: > >> 3666: // Auxiliary, read an string specified as count + string >> 3667: static >> 3668: cmsBool ReadCountAndString(struct _cms_typehandler_struct* self, cmsIOHANDLER* io, cmsMLU* mlu, cmsUInt32Number* SizeOfTag, const char* Section) > > As @kevinrushforth mentioned, we usually don't modify the source from external libraries. You should report and fix the problem upstream. Filed https://github.com/mm2/Little-CMS/pull/313 for this ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From djelinski at openjdk.java.net Wed Apr 6 14:12:17 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 14:12:17 GMT Subject: RFR: 8284444: Sting typo [v2] In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: > This patch adds missing `r` in `string`s Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Revert liblcms changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8125/files - new: https://git.openjdk.java.net/jdk/pull/8125/files/755c7084..68ce6ebd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8125.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125 PR: https://git.openjdk.java.net/jdk/pull/8125 From djelinski at openjdk.java.net Wed Apr 6 14:15:36 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 14:15:36 GMT Subject: RFR: 8284444: Sting typo [v2] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 13:36:05 GMT, Alexey Ivanov wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert liblcms changes > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63: > >> 61: message.creating-association-with-null-extension=Creating association with null extension. >> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required. >> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build . > > I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence. right; without the space the period would appear to be part of the version pattern. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From naoto at openjdk.java.net Wed Apr 6 15:52:37 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Apr 2022 15:52:37 GMT Subject: RFR: 8284444: Sting typo [v2] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 14:12:17 GMT, Daniel Jeli?ski wrote: >> This patch adds missing `r` in `string`s > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Revert liblcms changes src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63: > 61: * RFC 3454. > 62: * StringPrep prepares Unicode strings for use in network protocols. > 63: * Profiles of StringPrep are set of rules and data according to which the These also come from the upstream ICU4J project and should be corrected there. https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27 ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From djelinski at openjdk.java.net Wed Apr 6 16:47:17 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 16:47:17 GMT Subject: RFR: 8284444: Sting typo [v3] In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: > This patch adds missing `r` in `string`s Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - revert xalan changes - revert icu changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8125/files - new: https://git.openjdk.java.net/jdk/pull/8125/files/68ce6ebd..1ec0314e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8125&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8125.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8125/head:pull/8125 PR: https://git.openjdk.java.net/jdk/pull/8125 From djelinski at openjdk.java.net Wed Apr 6 16:51:43 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Apr 2022 16:51:43 GMT Subject: RFR: 8284444: Sting typo [v2] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 15:49:06 GMT, Naoto Sato wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert liblcms changes > > src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63: > >> 61: * RFC 3454. >> 62: * StringPrep prepares Unicode strings for use in network protocols. >> 63: * Profiles of StringPrep are set of rules and data according to which the > > These also come from the upstream ICU4J project and should be corrected there. > https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27 Thanks, reverted. Also reverted Xalan changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From naoto at openjdk.java.net Wed Apr 6 16:55:35 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Apr 2022 16:55:35 GMT Subject: RFR: 8284444: Sting typo [v2] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 16:48:38 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63: >> >>> 61: * RFC 3454. >>> 62: * StringPrep prepares Unicode strings for use in network protocols. >>> 63: * Profiles of StringPrep are set of rules and data according to which the >> >> These also come from the upstream ICU4J project and should be corrected there. >> https://github.com/unicode-org/icu/blob/4833cc89b2fae2e8863b46bf1dc785964847e882/icu4j/main/classes/core/src/com/ibm/icu/text/StringPrep.java#L27 > > Thanks, reverted. Also reverted Xalan changes. Good. Thanks for reverting it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From naoto at openjdk.java.net Wed Apr 6 17:52:08 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 6 Apr 2022 17:52:08 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test Message-ID: This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. ------------- Commit messages: - 8283698: Refactor Locale constructors used in src/test Changes: https://git.openjdk.java.net/jdk/pull/8130/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8130&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283698 Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod Patch: https://git.openjdk.java.net/jdk/pull/8130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130 PR: https://git.openjdk.java.net/jdk/pull/8130 From kcr at openjdk.java.net Wed Apr 6 17:56:40 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 17:56:40 GMT Subject: RFR: 8284444: Sting typo [v3] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski wrote: >> This patch adds missing `r` in `string`s > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - revert xalan changes > - revert icu changes The `jpackage` part of the fix looks good. Btw, there are translated files for 3 other languages (German, Japanese, Simplified Chinese), so I double-checked the translation for each, and they already say "string" (I guess whoever translated it just assumed it was meant to be "string" when they took the English phrase). ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/8125 From kcr at openjdk.java.net Wed Apr 6 17:56:40 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 17:56:40 GMT Subject: RFR: 8284444: Sting typo [v3] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 14:12:49 GMT, Daniel Jeli?ski wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties line 63: >> >>> 61: message.creating-association-with-null-extension=Creating association with null extension. >>> 62: message.wrong-tool-version=Detected [{0}] version {1} but version {2} is required. >>> 63: message.version-string-too-many-components=Version string may have up to 3 components - major.minor.build . >> >> I wonder whether the space before the period is required at the end of the sentence. Perhaps, it's to separate a property name from the end of the sentence. > > right; without the space the period would appear to be part of the version pattern. Yes, I believe this is why it was done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From aivanov at openjdk.java.net Wed Apr 6 18:10:40 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 6 Apr 2022 18:10:40 GMT Subject: RFR: 8284444: Sting typo [v3] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski wrote: >> This patch adds missing `r` in `string`s > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - revert xalan changes > - revert icu changes The changes look fine to me now. Yet there are no changes in the client area any more. So you'll have to get additional approvals. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8125 From iris at openjdk.java.net Wed Apr 6 19:36:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 6 Apr 2022 19:36:40 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From mgronlun at openjdk.java.net Wed Apr 6 20:49:48 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Apr 2022 20:49:48 GMT Subject: RFR: 8284444: Sting typo [v3] In-Reply-To: References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 16:47:17 GMT, Daniel Jeli?ski wrote: >> This patch adds missing `r` in `string`s > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - revert xalan changes > - revert icu changes JFR changes look fine, thank you. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8125 From joehw at openjdk.java.net Thu Apr 7 00:13:45 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:13:45 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: > 79: > 80: /** > 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); Locale.France? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 00:20:31 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:20:31 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131: > 129: > 130: // Tests with the Japanese imperial calendar > 131: Locale calendarLocale = Locale.of("ja", "JP", "JP"); Locale.JAPAN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 00:31:55 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 00:31:55 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: > 61: Locale.of("it", "IT", "EURO"), > 62: Locale.forLanguageTag("de-AT"), > 63: Locale.forLanguageTag("fr-CH"), Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. test/jdk/java/text/Format/common/Bug6215962.java line 58: > 56: check(mf1, mf2, false); > 57: > 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP")); Locale.JAPAN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From naoto at openjdk.java.net Thu Apr 7 01:19:35 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 7 Apr 2022 01:19:35 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang wrote: >> This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. > > test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: > >> 79: >> 80: /** >> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); > > Locale.France? The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here. > test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: > >> 61: Locale.of("it", "IT", "EURO"), >> 62: Locale.forLanguageTag("de-AT"), >> 63: Locale.forLanguageTag("fr-CH"), > > Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors. > test/jdk/java/text/Format/common/Bug6215962.java line 58: > >> 56: check(mf1, mf2, false); >> 57: >> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP")); > > Locale.JAPAN? The test intends to compare the generated `MessageFormat` objects (`mf2` & `mf1`) from using a constant `Locale.JAPAN` and the factory method. So I believe leaving it as `Locale.of()` makes sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 04:51:38 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:51:38 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: <0Zxp9nACKCy12wn8Viwd5lYHz3KXojuy02cZLiz8Wiw=.f1a9f3b3-8cfb-4845-87e7-bef9b69ada8a@github.com> On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato wrote: >> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81: >> >>> 79: >>> 80: /** >>> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", ""); >> >> Locale.France? > > The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, `country`, and `variant`, then create a `Locale` using those 3 elements. Changing it to `Locale.FRANCE` does not seem right here. I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 04:59:39 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:59:39 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From joehw at openjdk.java.net Thu Apr 7 04:59:40 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 7 Apr 2022 04:59:40 GMT Subject: RFR: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato wrote: >> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63: >> >>> 61: Locale.of("it", "IT", "EURO"), >>> 62: Locale.forLanguageTag("de-AT"), >>> 63: Locale.forLanguageTag("fr-CH"), >> >> Use the new factory? Ok not to change as these are tests and there are too many of them. It's not deprecated anyways. > > `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it validates the input language tag, while `Locale.of()` doesn't as well as Locale constructors. Ok, I didn't realize the existing method is preferred over the new method in creating a Locale. The javadoc does state that it does not make any syntactic checks. That's good to know. ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From fjiang at openjdk.java.net Thu Apr 7 05:55:01 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Thu, 7 Apr 2022 05:55:01 GMT Subject: RFR: 8284495: [testbug] Adapt nsk tests to the RISC-V platform Message-ID: Add riscv which don't have shared memory connector. Following tests passed with this patch and [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66): - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java - vmTestbase/nsk/jdb/options/connect/connect005/connect005.java - vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java - vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java - vmTestbase/nsk/jdi/AttachingConnector/attach/attach005/TestDescription.java - vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend003/TestDescription.java - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002/TestDescription.java - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004/TestDescription.java - vmTestbase/nsk/jdi/ListeningConnector/accept/accept002/TestDescription.java ------------- Commit messages: - [testbug] Adapt nsk tests to the RISC-V platform Changes: https://git.openjdk.java.net/jdk/pull/8137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284495 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8137/head:pull/8137 PR: https://git.openjdk.java.net/jdk/pull/8137 From stuefe at openjdk.java.net Thu Apr 7 13:38:07 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 13:38:07 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 17:51:28 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Templatize BitSet for MEMFLAGS Hi @coleenp and @rkennke, Since the JVMTI heap walk usually walks the whole heap, the bitmap may not be as sparse as we think. It would materialize a lot - possibly all - of its fragments. The increased memory consumption during JVMTI heap walk may mess with JVMTI agents using heapwalking for analysis in OOM situations. But I'm not against this. It is clearly more maintainable. A lot clearer. And if it helps lilliput, we save a lot more memory than we pay here. --- About this PR: You moved Bitset to general-purpose land. Now its a general purpose class, and should be more versatile and better documented. A comment would be good, at least for the structure itself. Proposal (feel free to modify/extend): BitSet is a sparse bitmap describing a memory range. It holds one bit per xxx-aligned address. Its underlying backing memory is allocated on-demand only, in yyy-sized fragments. Fragments are never deleted. The underlying memory is allocated from C-Heap. I would also rename the function, since it is very unclear what the difference is between BitMap and BitSet. E.g. "AddressMap" "SparseAddressMap", or similar. fragment size xxx and alignment yyy would ideally be configurable at compile time. At the moment, it feels very "heapish". It uses oop. It uses LogMinObjAlignmentInBytes. Ideally we would not include oop.hpp, and not know about oops. Especially the dependency on LogMinObjAlignmentInBytes is not optimal: that is a runtime variable depending on `-XX:ObjectAlignmentInBytes`. It would be good if that could be a compile time constant. Right now, IIUC, `BitSet::addr_to_bit()` will always load the alignment from memory. As a general purpose structure, some gtests would be nice. Maybe in some future RFE. --- A general thought, maybe for a future RFE: We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. As a sketch: class BitMap { // bitmap holding one bit per 64M fragment of the underlying bitmap backing memory BitMap _commit_map; inline void set_bit(idx_t bit) { // - find out which fragment the bit lives in // - if (commitmap[fragmentid] == 0) { commit_fragment(); commitmap[fragmentid]=1; } // - set bit } // same for clear_bit() bool at(idx_t index) const { // - find out which fragment the bit lives in // - if (commitmap[fragmentid] == 0) { return false; } // bit has never been set, is therefore zero // - else return the actual bit } } The sparse-handling part would have to be switchable at compile time so that we won't pay for it in non-sparse BitMap. I believe this solution could be simpler than a new separate utility class, and be more versatile. Would be interesting to know @kimbarrett 's opinion. But this can be done of course in a separate RFE. If at all. Cheers, Thomas src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 42: > 40: EdgeQueue* _edge_queue; > 41: EdgeStore* _edge_store; > 42: BitSet* _mark_bits; It feels weird to have an implementation detail like "under which NMT category is the bitmap allocated" in the interface of all functions now. I don't have a better idea for now, but how about we at least typedef this thing in JFR space somewhere? E.g. `typedef BitSet JFRBitSet` ? src/hotspot/share/prims/jvmtiTagMap.cpp line 1337: > 1335: // Stack allocated class to help ensure that ObjectMarker is used > 1336: // correctly. Constructor initializes ObjectMarker, destructor calls > 1337: // ObjectMarker's done() function to restore object headers. This comment is outdated, right? src/hotspot/share/prims/jvmtiTagMap.cpp line 1338: > 1336: // correctly. Constructor initializes ObjectMarker, destructor calls > 1337: // ObjectMarker's done() function to restore object headers. > 1338: class ObjectMarker : public StackObj { Maybe, for a future RFE: Ideally this would live as member in the VMOp, constructed and cleaned up by it. No stack obj nor global pointer needed then. We'd have to fix those few callers that have no access to the calling VMOp though. src/hotspot/share/utilities/bitset.hpp line 54: > 52: } > 53: }; > 54: We can loose the "protected" below since we never derive from this class src/hotspot/share/utilities/bitset.inline.hpp line 94: > 92: template > 93: inline BitMap::idx_t BitSet::addr_to_bit(uintptr_t addr) const { > 94: return (addr & _bitmap_granularity_mask) >> LogMinObjAlignmentInBytes; See my earlier comment. This is a runtime variable, would be nice to have this as compile time constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From lmesnik at openjdk.java.net Thu Apr 7 14:52:40 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 7 Apr 2022 14:52:40 GMT Subject: RFR: 8284495: [testbug] Adapt nsk tests to the RISC-V platform In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 05:47:56 GMT, Feilong Jiang wrote: > Add riscv which doesn't have shared memory connector. > Following tests passed with this patch and [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66): > > - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java > - vmTestbase/nsk/jdb/options/connect/connect005/connect005.java > - vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach005/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend003/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004/TestDescription.java > - vmTestbase/nsk/jdi/ListeningConnector/accept/accept002/TestDescription.java Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8137 From djelinski at openjdk.java.net Thu Apr 7 14:58:43 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 7 Apr 2022 14:58:43 GMT Subject: Integrated: 8284444: Sting typo In-Reply-To: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> References: <6dV8QfrkKltmL7CnwYYMDMhEMBHnEcYmrtdrZZITwl4=.6963f840-ea5f-4034-824a-99b776b53af5@github.com> Message-ID: On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeli?ski wrote: > This patch adds missing `r` in `string`s This pull request has now been integrated. Changeset: 5bafcfdc Author: Daniel Jeli?ski URL: https://git.openjdk.java.net/jdk/commit/5bafcfdc171b5a514ecf620703e77fa2f4a49c58 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod 8284444: Sting typo Reviewed-by: kcr, aivanov, mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/8125 From rkennke at openjdk.java.net Thu Apr 7 15:15:44 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 15:15:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> On Thu, 7 Apr 2022 13:31:31 GMT, Thomas Stuefe wrote: > Since the JVMTI heap walk usually walks the whole heap, the bitmap may not be as sparse as we think. It would materialize a lot - possibly all - of its fragments. The increased memory consumption during JVMTI heap walk may mess with JVMTI agents using heapwalking for analysis in OOM situations. The on-demand allocation of fragments should be a lot better than what I proposed before (in the Lilliput PR). The Java heap is typically never fully occupied, Java OOM situations aside. Heap walking may also start from a single object, in which case we would likely only walk a small subset of the heap. The current solution already allocates 2x4000x8 bytes by default for stashing locked and hashed headers. Also, only because Java runs out of memory on the heap doesn't mean that it's likely that we're also running out of native heap. The maximum memory usage should be around 1/64th of the Java heap size on default object alignment. > About this PR: > > You moved Bitset to general-purpose land. Now its a general purpose class, and should be more versatile and better documented. A comment would be good, at least for the structure itself. Proposal (feel free to modify/extend): > > ``` > BitSet is a sparse bitmap describing a memory range. It holds one bit per xxx-aligned > address. Its underlying backing memory is allocated on-demand only, in yyy-sized > fragments. Fragments are never deleted. The underlying memory is allocated from C-Heap. > ``` Yes, I will do that. > I would also rename the function, since it is very unclear what the difference is between BitMap and BitSet. E.g. "AddressMap" "SparseAddressMap", or similar. As you noted elsewhere, it is currently very heap/object-centric. We could name it ObjectBitSet or something like that for now. I would not want to implement the (reasonable) abstractions that you're proposing below, simply because it's not used as such, currently. Whenever we need such use, or have a desire to merge BitMap and ObjectBitSet, then we shall consider the abstractions, but now it seems a bit premature. > fragment size xxx and alignment yyy would ideally be configurable at compile time. At the moment, it feels very "heapish". It uses oop. It uses LogMinObjAlignmentInBytes. Ideally we would not include oop.hpp, and not know about oops. > Especially the dependency on LogMinObjAlignmentInBytes is not optimal: that is a runtime variable depending on `-XX:ObjectAlignmentInBytes`. It would be good if that could be a compile time constant. Right now, IIUC, `BitSet::addr_to_bit()` will always load the alignment from memory. Yes, but we *do* want to use it as object bitmap, and thus should know about ObjAlignmentInBytes, and this is determined at run-time only. > As a general purpose structure, some gtests would be nice. Maybe in some future RFE. Indeed. I will look into adding some. > A general thought, maybe for a future RFE: > > We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > > One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. > > As a sketch: > > ``` > class BitMap { > > // bitmap holding one bit per 64M fragment of the underlying bitmap backing memory > BitMap _commit_map; > > inline void set_bit(idx_t bit) { > // - find out which fragment the bit lives in > // - if (commitmap[fragmentid] == 0) { commit_fragment(); commitmap[fragmentid]=1; } > // - set bit > } > > // same for clear_bit() > > bool at(idx_t index) const { > // - find out which fragment the bit lives in > // - if (commitmap[fragmentid] == 0) { return false; } // bit has never been set, is therefore zero > // - else return the actual bit > } > > } > ``` > > The sparse-handling part would have to be switchable at compile time so that we won't pay for it in non-sparse BitMap. > > I believe this solution could be simpler than a new separate utility class, and be more versatile. Would be interesting to know @kimbarrett 's opinion. > > But this can be done of course in a separate RFE. If at all. Yes, let's do that as follow-up RFE. Thanks, Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 16:40:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 16:40:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 17:51:28 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Templatize BitSet for MEMFLAGS If you add my proposed comment for bitset.hpp, or some variation of it, then the rest looks good to me in its current form. Thanks for considering my proposals! Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 17:20:41 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 17:20:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: References: Message-ID: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: - Add comment describing ObjectBitSet - Refactor JVMTI usage of ObjectBitSet - Typedef ObjectBitSet to JFRBitSet in JFR code - Rename BitSet to ObjectBitSet ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/6d0f429d..e14f8d73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=03-04 Stats: 603 lines in 10 files changed: 284 ins; 293 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 17:22:16 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 17:22:16 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 16:37:22 GMT, Thomas Stuefe wrote: > If you add my proposed comment for bitset.hpp, or some variation of it, then the rest looks good to me in its current form. Thanks for considering my proposals! > > Thanks, Thomas I did that, and some more of your suggestions, please have another look! I refactored the JVMTI usage. Instead of being global in ObjectMarker, the ObjectBitSet* is now in the VM_Op, except that I also needed to drag it into CallbackInvoker, where it is a static field again. This whole class can/should probably be refactored to not be AllStatic, but also local to the VM_Op, but that seems a task for a follow-up as well. Unfortunately, there is no good place to reset the CallbackInvoker, but that is also true for all other of its fields already. WDYT now? ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 17:51:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 17:51:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet Looks better :) Placed in the VMOp this is less confusing. Also, less code. Small remarks inline, feel free to ignore them. We are entering nitpicking territory here. Cheers, Thomas src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 37: > 35: class ObjectBitSet; > 36: > 37: typedef ObjectBitSet JFRBitSet; Can you include memory/allocation.hpp for the MEMFLAGS? iterator.hpp already does, but better to be include-clean src/hotspot/share/prims/jvmtiTagMap.cpp line 2252: > 2250: GrowableArray* _visit_stack; // the visit stack > 2251: > 2252: JVMTIBitSet* _bitset; Small nit: You may consider making this a simple member, then you can get rid of the dynamic allocation and deallocation. Just feed the address of the member to CallbackInvoker. If you are worried about stack size, Bitset is not that big, 100ish bytes or so. Should still be fine to put the VMOp on the stack. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 17:51:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 17:51:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:22:12 GMT, Thomas Stuefe wrote: >> Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add comment describing ObjectBitSet >> - Refactor JVMTI usage of ObjectBitSet >> - Typedef ObjectBitSet to JFRBitSet in JFR code >> - Rename BitSet to ObjectBitSet > > src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.hpp line 37: > >> 35: class ObjectBitSet; >> 36: >> 37: typedef ObjectBitSet JFRBitSet; > > Can you include memory/allocation.hpp for the MEMFLAGS? iterator.hpp already does, but better to be include-clean Optional: move this typedef to an own jfr/leakprofiler/utilities/jfrbitset.hpp and include that one instead of objectbitset.inline.hpp in the callee cpp files ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Thu Apr 7 18:02:57 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 7 Apr 2022 18:02:57 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet About https://github.com/openjdk/jdk/pull/8148, could you wait until that one is in? Would make it easier to backport Zhengyus change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 18:28:42 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 18:28:42 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/e14f8d73..b525f2da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=04-05 Stats: 58 lines in 7 files changed: 38 ins; 14 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Thu Apr 7 18:28:43 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Apr 2022 18:28:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v5] In-Reply-To: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> References: <1CwiXwbDhtkDbV556jogJzJiIyn6TdMYG9SMN-Axk-o=.80e6543f-e78a-4ba8-9afb-400eea502fd2@github.com> Message-ID: On Thu, 7 Apr 2022 17:20:41 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment describing ObjectBitSet > - Refactor JVMTI usage of ObjectBitSet > - Typedef ObjectBitSet to JFRBitSet in JFR code > - Rename BitSet to ObjectBitSet > About #8148, could you wait until that one is in? Would make it easier to backport Zhengyus change. Thanks for the heads-up! Yes I will wait. I also implemented your latest suggestions. While I wait for #8148, I will also add some gtests. Then it should be good to go. I also filed: https://bugs.openjdk.java.net/browse/JDK-8284543 ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From cjplummer at openjdk.java.net Thu Apr 7 19:05:41 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Apr 2022 19:05:41 GMT Subject: Integrated: 8284043: com/sun/jdi/MethodInvokeWithTraceOnTest.java failing with com.sun.jdi.ObjectCollectedException In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 04:09:55 GMT, Chris Plummer wrote: > Test is getting an `com.sun.jdi.ObjectCollectedException` during an invoke. The reason is because an allocated object is not being prevented from being gc'd: > > > StringReference stringObj = vm().mirrorOf("test string"); > ... > classType.invokeMethod(thread, printMethod, Collections.singletonList(stringObj), invokeOptions); > > > Need a `disableCollection()` on `stringObj` since threads are resumed during the invoke, allowing it to be collected. This pull request has now been integrated. Changeset: e98c32d6 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/e98c32d6b6621f00b82089c8a92913234e6abe5c Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284043: com/sun/jdi/MethodInvokeWithTraceOnTest.java failing with com.sun.jdi.ObjectCollectedException Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8052 From cjplummer at openjdk.java.net Thu Apr 7 19:32:40 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Apr 2022 19:32:40 GMT Subject: RFR: 8284495: [testbug] Adapt nsk tests to the RISC-V platform In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 05:47:56 GMT, Feilong Jiang wrote: > Add riscv which doesn't have shared memory connector. > Following tests passed with this patch and [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66): > > - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java > - vmTestbase/nsk/jdb/options/connect/connect005/connect005.java > - vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach005/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend003/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004/TestDescription.java > - vmTestbase/nsk/jdi/ListeningConnector/accept/accept002/TestDescription.java Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8137 From zgu at openjdk.java.net Thu Apr 7 19:37:35 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 7 Apr 2022 19:37:35 GMT Subject: RFR: 8284458: CodeHeapState::aggregate() leaks blob_name [v3] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 10:12:21 GMT, Lutz Schmidt wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > Looks good to me. > Good catch! Thanks for finding and fixing the leak. Thanks for the review, @RealLucy ------------- PR: https://git.openjdk.java.net/jdk/pull/8132 From lmesnik at openjdk.java.net Thu Apr 7 20:12:40 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 7 Apr 2022 20:12:40 GMT Subject: RFR: 8284458: CodeHeapState::aggregate() leaks blob_name [v3] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 02:57:29 GMT, Zhengyu Gu wrote: >> Please review this small patch to fix a possible memory leak. >> >> Test: >> - [x] hotspot_serviceability > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Fix Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8132 From zgu at openjdk.java.net Thu Apr 7 20:41:42 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 7 Apr 2022 20:41:42 GMT Subject: RFR: 8284458: CodeHeapState::aggregate() leaks blob_name [v3] In-Reply-To: References: Message-ID: <5Thno1vcRba0gH5PMJmxNxqiZUR8kXUsLHmp_bNwv-E=.b7cb9077-fdfd-452b-8c1b-9c1df4e2d381@github.com> On Thu, 7 Apr 2022 20:09:24 GMT, Leonid Mesnik wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > Marked as reviewed by lmesnik (Reviewer). Thanks, @lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/8132 From zgu at openjdk.java.net Thu Apr 7 20:41:43 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 7 Apr 2022 20:41:43 GMT Subject: Integrated: 8284458: CodeHeapState::aggregate() leaks blob_name In-Reply-To: References: Message-ID: <562rBFYU4Bv-FgM2EQT8gPKvwhtdFCzoG7senCJIoLY=.77980d49-0357-4581-8b1d-9ec7ef87f619@github.com> On Wed, 6 Apr 2022 23:30:13 GMT, Zhengyu Gu wrote: > Please review this small patch to fix a possible memory leak. > > Test: > - [x] hotspot_serviceability This pull request has now been integrated. Changeset: d4a48843 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/d4a48843856e3d80a58d5a0a26dff6c4d349dca9 Stats: 10 lines in 1 file changed: 4 ins; 3 del; 3 mod 8284458: CodeHeapState::aggregate() leaks blob_name Reviewed-by: lucy, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/8132 From lmesnik at openjdk.java.net Thu Apr 7 23:36:01 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 7 Apr 2022 23:36:01 GMT Subject: RFR: 8284556: Ensure reachability of classes in runtime/whitebox/TestHiddenClassIsAlive.java and serviceability/dcmd/vm/ClassLoaderHierarchyTest.java Message-ID: Tests are updated to ensure that classes are alive while test checks them. Actually, fixed by @AlanBateman in repo-loom. ------------- Commit messages: - 8284556: Ensure reachability of classes in runtime/whitebox/TestHiddenClassIsAlive.java and serviceability/dcmd/vm/ClassLoaderHierarchyTest.java Changes: https://git.openjdk.java.net/jdk/pull/8152/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8152&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284556 Stats: 11 lines in 2 files changed: 7 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8152.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8152/head:pull/8152 PR: https://git.openjdk.java.net/jdk/pull/8152 From cjplummer at openjdk.java.net Fri Apr 8 00:07:41 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 8 Apr 2022 00:07:41 GMT Subject: RFR: 8284556: Ensure reachability of classes in runtime/whitebox/TestHiddenClassIsAlive.java and serviceability/dcmd/vm/ClassLoaderHierarchyTest.java In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 23:29:41 GMT, Leonid Mesnik wrote: > Tests are updated to ensure that classes are alive while test checks them. > Actually, fixed by @AlanBateman in repo-loom. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8152 From fjiang at openjdk.java.net Fri Apr 8 00:59:40 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Fri, 8 Apr 2022 00:59:40 GMT Subject: RFR: 8284495: [testbug] Adapt nsk tests to the RISC-V platform In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 14:49:41 GMT, Leonid Mesnik wrote: >> Add riscv which doesn't have shared memory connector. >> Following tests passed with this patch and [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66): >> >> - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java >> - vmTestbase/nsk/jdb/options/connect/connect005/connect005.java >> - vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java >> - vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java >> - vmTestbase/nsk/jdi/AttachingConnector/attach/attach005/TestDescription.java >> - vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend003/TestDescription.java >> - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002/TestDescription.java >> - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004/TestDescription.java >> - vmTestbase/nsk/jdi/ListeningConnector/accept/accept002/TestDescription.java > > Marked as reviewed by lmesnik (Reviewer). @lmesnik @plummercj Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8137 From fjiang at openjdk.java.net Fri Apr 8 01:02:46 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Fri, 8 Apr 2022 01:02:46 GMT Subject: Integrated: 8284495: [testbug] Adapt nsk tests to the RISC-V platform In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 05:47:56 GMT, Feilong Jiang wrote: > Add riscv which doesn't have shared memory connector. > Following tests passed with this patch and [CODETOOLS-7903138](https://github.com/openjdk/jtreg/pull/66): > > - vmTestbase/nsk/jdb/options/connect/connect003/connect003.java > - vmTestbase/nsk/jdb/options/connect/connect005/connect005.java > - vmTestbase/nsk/jdb/options/listconnectors/listconnectors001/listconnectors001.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach002/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attach/attach005/TestDescription.java > - vmTestbase/nsk/jdi/AttachingConnector/attachnosuspend/attachnosuspend003/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch002/TestDescription.java > - vmTestbase/nsk/jdi/LaunchingConnector/launch/launch004/TestDescription.java > - vmTestbase/nsk/jdi/ListeningConnector/accept/accept002/TestDescription.java This pull request has now been integrated. Changeset: de9596c2 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/de9596c2905061443c93450087a888c7c01d1bc2 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8284495: [testbug] Adapt nsk tests to the RISC-V platform Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/8137 From kbarrett at openjdk.java.net Fri Apr 8 02:05:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Apr 2022 02:05:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> Message-ID: <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> On Mon, 4 Apr 2022 21:53:28 GMT, Roman Kennke wrote: > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From kbarrett at openjdk.java.net Fri Apr 8 02:18:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Apr 2022 02:18:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > Slapping a template parameter on everything isn't necessarily a good idea. [...] There is a design principle that one should strive to only impose a template parameter on code that actually needs it. According to that principle, most of the bitset is completely independent of the MEMFLAGS value, and shouldn't be parameterized on it. There's a well-known paper about this: http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2009/n2911.pdf (the so-called SCARY paper). I learned a lot from that paper. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 03:43:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 03:43:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> Message-ID: On Fri, 8 Apr 2022 02:01:50 GMT, Kim Barrett wrote: > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. I never liked MEMFLAGS as template parameter. A runtime parameter would it make easier to use a general-purpose data structure on behalf of a subsystem and account its memory to that subsystem, while still being able to pass it around as a simple pointer to other utility functions. But here Roman squirreled the template definition away into a typedef, so I think we could cleanup MEMFLAG usage in a separate RFE? (we also should move MEMFLAGS to an own header file, btw, to avoid having to pull allocation.hpp every time) ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From iklam at openjdk.java.net Fri Apr 8 03:53:54 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 03:53:54 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 12:44:35 GMT, Yasumasa Suenaga wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments The code changes look good, but I think the comment should be cleaned up. src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java line 117: > 115: * skip these duplicated directories. > 116: * Host and container devices could have the same inode value, > 117: * so we also need to check the device id. I would suggest rewording the comments from Line 111 to 117 to the following to be more concise: * When cgroups is enabled, the directory /proc/{pid}/root/tmp may * exist even if the given pid is not running inside a container. In * this case, this directory is usually the same as /tmp and should * be skipped, or else we would get duplicated hsperfdata files. * This case can be detected if the inode and device id of * /proc/{pid}/root/tmp are the same as /tmp. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8103 From stuefe at openjdk.java.net Fri Apr 8 04:20:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 04:20:39 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated BTW, one neat solution to the MEMFLAGS problem would be to make it a property of the thread, and stackable. With sort of a MemflagMark. Each Thread could have a property "default MEMFLAGS", set with a MemFlagMark, and that gets used by default with every malloc in this thread. This way we may be able to get rid of a lot (most?) manual MEMFLAG declarations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 04:58:46 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 04:58:46 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v2] In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 12:44:35 GMT, Yasumasa Suenaga wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Looks good to me (with @iklam's Comment changes). Thans for fixing. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8103 From ysuenaga at openjdk.java.net Fri Apr 8 08:34:24 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Apr 2022 08:34:24 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v3] In-Reply-To: References: Message-ID: <3zJuch1W-BpFlTFBNofzq7782u0MRbKsGnuBmP7KoEY=.dab96610-e9f4-44d8-ab54-bfa18bad3663@github.com> > jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. > > For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. > > > $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 > / # > / # stat /tmp > File: /tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: efh/239d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:51:37.000000000 > Change: 2022-04-05 08:51:37.000000000 > > / # stat /proc/1/root/tmp > File: /proc/1/root/tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: e1h/225d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:50:42.000000000 > Change: 2022-04-05 08:50:42.000000000 Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Update the comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8103/files - new: https://git.openjdk.java.net/jdk/pull/8103/files/0e0ccbe0..328e7140 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8103&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8103&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8103.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8103/head:pull/8103 PR: https://git.openjdk.java.net/jdk/pull/8103 From ysuenaga at openjdk.java.net Fri Apr 8 08:34:25 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 8 Apr 2022 08:34:25 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v2] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 03:50:10 GMT, Ioi Lam wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments > > The code changes look good, but I think the comment should be cleaned up. Thanks @iklam and @tstuefe ! I updated the comment as you shown. ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From tschatzl at openjdk.java.net Fri Apr 8 09:10:43 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Apr 2022 09:10:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v4] In-Reply-To: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> References: <9LOZ_IbIoIHs0gVF_YI4cvIrlOUf_FvzykRZq2Dqmz8=.76583c5a-30be-45d7-b853-d7f771ed20fd@github.com> Message-ID: On Thu, 7 Apr 2022 15:11:54 GMT, Roman Kennke wrote: > A general thought, maybe for a future RFE: > >We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > >One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. Please don't do this. `BitMap` (well, `BitMapView`) is also used as a lightweight way to overlay it on arbitrary memory temporarily (i.e. remembered sets bitmaps). This typically boils down to no additional memory usage (and overhead) at all. So any additional memory usage or initialization should not be added lightly. Also in most other cases, `BitMap` is used for very tiny bitmaps anyway, this would just add unnecessary functionality (and overhead) for 99% of the usage of `BitMap`. Further GCs are using `BitMap` to implement such sparse bit sets already, managing their memory with the corresponding Java heap memory; so adding this functionality at the `BitMap` level would just duplicate functionality with probably not-so-hilarious side effects. I also *do* think that the use cases for a dense `BitMap` are significantly different from (huge) sparse "BitMap"s to warrant its own separate class (not saying that one couldn't use the other internally, or that if that `BitSet` could be reused in GCs if configurable enough). I am also not sure that the automatic lazy backing of the OS isn't sufficient for these use cases (e.g. JVMTI) too. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 09:44:48 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 09:44:48 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Hi Thomas, > > A general thought, maybe for a future RFE: > > We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free. > > One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment. > > Please don't do this. `BitMap` (well, `BitMapView`) is also used as a lightweight way to overlay it on arbitrary memory temporarily (i.e. remembered sets bitmaps). This typically boils down to no additional memory usage (and overhead) at all. So any additional memory usage or initialization should not be added lightly. Also in most other cases, `BitMap` is used for very tiny bitmaps anyway, this would just add unnecessary functionality (and overhead) for 99% of the usage of `BitMap`. > > Further GCs are using `BitMap` to implement such sparse bit sets already, managing their memory with the corresponding Java heap memory; so adding this functionality at the `BitMap` level would just duplicate functionality with probably not-so-hilarious side effects. > Yes, you are right. I had some more time to think about this and came to the same conclusion. Also abstracting bitwise getters and setters as I thought originally would probably not be enough. > I also _do_ think that the use cases for a dense `BitMap` are significantly different from (huge) sparse "BitMap"s to warrant its own separate class (not saying that one couldn't use the other internally, or that if that `BitSet` could be reused in GCs if configurable enough). > > I am also not sure that the automatic lazy backing of the OS isn't sufficient for these use cases (e.g. JVMTI) too. I'm not sure about this. We often run against the commit charge of the underlying OS, which seems to be more frequent than running out of physical memory. I think voluntary uncommit does make sense. Whether the libc actually uncommits on free() is a different question, but in this case, I think they do, the fragments are large enough. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Fri Apr 8 12:05:44 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 12:05:44 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: <2V13Kr51baZQzWRorTT52LphO6pvNw3rugJrbC1mksA=.29cb7364-fe29-461d-864f-4c0c164502bd@github.com> <--W_f_6TlAnxqAKsvy0G8UlfJbDr32SEuqMZ_Uc5Hw0=.e0ad488c-ce07-4e5e-8c34-ee1ddc891749@github.com> <4WleT5oWgzYka9hUYg1QiAld3OeC_hS41LJILk30fls=.92015a62-ac2f-4bb8-b550-45279f924c0b@github.com> <1-bj5KJVcCxQUTmH22mBXWF9kdPBEQES3fYe6SzJZVg=.9101452c-db61-4486-b092-4003013f5199@github.com> Message-ID: On Fri, 8 Apr 2022 03:40:41 GMT, Thomas Stuefe wrote: > > > One open question is which MEMFLAGS to use. mtTracing doesn't seem to be exactly right. Should I templatize BitSet and make JVMTI use mtServiceability and JRF use mtTracing as it did before? > > > > > > Yes, I think templatizing for MEMFLAGS makes sense (concurrentHashTable.hpp is too). > > I haven't had time to look at the code, but I don't know about this. Slapping a template parameter on everything isn't necessarily a good idea. We recently (JDK-8283368) undid exactly this sort of thing in the cardset code, instead making the MEMFLAGS value a runtime parameter provided at construction time. This avoids a bunch of generated code duplication, additional template syntax, and allows more implementation be put in .cpp files because it isn't a template. The trouble is that ObjectBitSet is a subclass of CHeapObj, which takes a template parameter for memflags itself. How could I avoid templatizing the ObjectBitSet itself? ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From coleenp at openjdk.java.net Fri Apr 8 13:02:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Apr 2022 13:02:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Fri Apr 8 14:20:41 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 14:20:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 12:59:26 GMT, Coleen Phillimore wrote: > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. Naa, I don't think this is justified. It isn't used as widely or frequently to warrant its own flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 14:54:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 14:54:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 14:17:06 GMT, Roman Kennke wrote: > > Here's an idea. Add an mtflag called mtBitMap and use that. There's plenty of bits in mt flags. > > Naa, I don't think this is justified. It isn't used as widely or frequently to warrant its own flag. Plus, it would muddy the water, since what we actually want is the memory accounted toward the subsystem on behalf of which we create the data structure. mtBitMap would be a bit like "mtArray" for GrowableArray. Note that there was the idea, and an associated JBS issue (https://bugs.openjdk.java.net/browse/JDK-8281819) of making NMT categories groupable in a one- or multi-layered hierarchy. That way, one could account to "mtGC" -> "mtBitSet", for instance. For now, I opt to either live with what we have with the typedef'ed BitSet, and leave MEMFLAG cleanups to a later RFE. Alternatively, make the MEMFLAG a runtime parameter of the bitset, use that for the heap allocated fragments, but use "mtInternal" for the actual class. I mean, those are just a few bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 14:54:42 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 14:54:42 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated Third alternative would be not to derive from CHeapObj at all, since we don't new it anywhere if I see correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From alanb at openjdk.java.net Fri Apr 8 15:03:28 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 8 Apr 2022 15:03:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) Message-ID: This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. We will refresh this PR periodically to pick up changes and fixes from the loom repo. Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284161 Stats: 101472 lines in 1116 files changed: 91922 ins; 4207 del; 5343 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Fri Apr 8 15:03:39 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Apr 2022 15:03:39 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From naoto at openjdk.java.net Fri Apr 8 15:26:35 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 8 Apr 2022 15:26:35 GMT Subject: Integrated: 8283698: Refactor Locale constructors used in src/test In-Reply-To: References: Message-ID: On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are simple replacements to Locale constructors with `Locale.of()` or Locale constants, such as `Locale.US`. This pull request has now been integrated. Changeset: d6b4693c Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod 8283698: Refactor Locale constructors used in src/test Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/8130 From iklam at openjdk.java.net Fri Apr 8 15:48:29 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 8 Apr 2022 15:48:29 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v3] In-Reply-To: <3zJuch1W-BpFlTFBNofzq7782u0MRbKsGnuBmP7KoEY=.dab96610-e9f4-44d8-ab54-bfa18bad3663@github.com> References: <3zJuch1W-BpFlTFBNofzq7782u0MRbKsGnuBmP7KoEY=.dab96610-e9f4-44d8-ab54-bfa18bad3663@github.com> Message-ID: On Fri, 8 Apr 2022 08:34:24 GMT, Yasumasa Suenaga wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update the comment Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From stuefe at openjdk.java.net Fri Apr 8 16:27:39 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 16:27:39 GMT Subject: RFR: 8284330: jcmd may not be able to find processes in the container [v3] In-Reply-To: <3zJuch1W-BpFlTFBNofzq7782u0MRbKsGnuBmP7KoEY=.dab96610-e9f4-44d8-ab54-bfa18bad3663@github.com> References: <3zJuch1W-BpFlTFBNofzq7782u0MRbKsGnuBmP7KoEY=.dab96610-e9f4-44d8-ab54-bfa18bad3663@github.com> Message-ID: On Fri, 8 Apr 2022 08:34:24 GMT, Yasumasa Suenaga wrote: >> jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. >> >> For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. >> >> >> $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 >> / # >> / # stat /tmp >> File: /tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: efh/239d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:51:37.000000000 >> Change: 2022-04-05 08:51:37.000000000 >> >> / # stat /proc/1/root/tmp >> File: /proc/1/root/tmp >> Size: 29 Blocks: 0 IO Block: 4096 directory >> Device: e1h/225d Inode: 135674931 Links: 1 >> Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2022-04-05 08:51:37.000000000 >> Modify: 2022-04-05 08:50:42.000000000 >> Change: 2022-04-05 08:50:42.000000000 > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Update the comment still good ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From rkennke at openjdk.java.net Fri Apr 8 16:47:53 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 16:47:53 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> References: <6m_aPm2bCCe1oQpZs6jAy2PWnigb7jmoRlM8Mz5Ffm0=.d7975987-fcf6-4dcb-ad35-3e4220855bb2@github.com> Message-ID: On Fri, 8 Apr 2022 15:00:22 GMT, Coleen Phillimore wrote: > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. Yes, at some point we need to allocate the fragments and fragments table. We could *perhaps* work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Fri Apr 8 17:03:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 8 Apr 2022 17:03:41 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 18:28:42 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated > > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. > > Yes, at some point we need to allocate the fragments and fragments table. We could _perhaps_ work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. (all bikeshedding since we all agree the current version is fine, no?) No, sorry, I meant make BitSet a normal class. Not derived from CHeapObj, since it gets not newed, only used via composition or on a stack. And give it a runtime parm to set the MEMFLAG. So: class BitSet { const MEMFLAGS _flags; public: BitSet(MEMFLAGS f = mtInternal) : _flags(f) {...} }; and use those flags for the c-heap allocation of the fragments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Fri Apr 8 17:35:09 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 17:35:09 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v7] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8283710 - Move JFRBitSet typedef into its own header; Make _bitset a direct member, not dynamically allocated - Add comment describing ObjectBitSet - Refactor JVMTI usage of ObjectBitSet - Typedef ObjectBitSet to JFRBitSet in JFR code - Rename BitSet to ObjectBitSet - Templatize BitSet for MEMFLAGS - Rename ObjectMarkerController -> ObjectMarker - Use (former JFR) BitSet for JVMTI object marking - Restore missing include - ... and 2 more: https://git.openjdk.java.net/jdk/compare/0a026759...9ea51d78 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=06 Stats: 774 lines in 12 files changed: 326 ins; 427 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Fri Apr 8 17:37:03 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 8 Apr 2022 17:37:03 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: Message-ID: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> On Fri, 8 Apr 2022 17:00:19 GMT, Thomas Stuefe wrote: > > > We must call new on it somewhere. I am not opposed to making this an mtFlags template then. This is a small point in this improvement. > > > > > > Yes, at some point we need to allocate the fragments and fragments table. We could _perhaps_ work around it by passing MEMFLAGS as constexpr, but I don't think this would change generated code much. > > (all bikeshedding since we all agree the current version is fine, no?) > > No, sorry, I meant make BitSet a normal class. Not derived from CHeapObj, since it gets not newed, only used via composition or on a stack. And give it a runtime parm to set the MEMFLAG. > > So: > > ``` > class BitSet { > const MEMFLAGS _flags; > public: > BitSet(MEMFLAGS f = mtInternal) : _flags(f) {...} > }; > ``` > > and use those flags for the c-heap allocation of the fragments. Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: switch (_flags) { case mtServiceability: ... new BitMapFragmentTable(); break; case mtServiceability: ... new BitMapFragmentTable(); break; default: ShouldNotReachHere(); } Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From duke at openjdk.java.net Fri Apr 8 18:39:59 2022 From: duke at openjdk.java.net (farhankhan04) Date: Fri, 8 Apr 2022 18:39:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <27Nx03MrIUd1fTR-T3GAGvt6aaX5_P-RUUVzd4pOgGE=.0194757d-30c9-48ec-bc6b-10195d39cfea@github.com> On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Marked as reviewed by farhankhan04 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Fri Apr 8 19:28:42 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 8 Apr 2022 19:28:42 GMT Subject: Integrated: 8284556: Ensure reachability of classes in runtime/whitebox/TestHiddenClassIsAlive.java and serviceability/dcmd/vm/ClassLoaderHierarchyTest.java In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 23:29:41 GMT, Leonid Mesnik wrote: > Tests are updated to ensure that classes are alive while test checks them. > Actually, fixed by @AlanBateman in repo-loom. This pull request has now been integrated. Changeset: a8c87526 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/a8c87526027bed750e3dcab78139b49bc0a05f83 Stats: 11 lines in 2 files changed: 7 ins; 2 del; 2 mod 8284556: Ensure reachability of classes in runtime/whitebox/TestHiddenClassIsAlive.java and serviceability/dcmd/vm/ClassLoaderHierarchyTest.java Reviewed-by: cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/8152 From lmesnik at openjdk.java.net Fri Apr 8 22:22:22 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 8 Apr 2022 22:22:22 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses Message-ID: The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" It is not a loom specific bug, it might happen in jdk/jdk also. The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. Also fix inlcudes some text refactoring to make push from loom smaller. ------------- Commit messages: - 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses Changes: https://git.openjdk.java.net/jdk/pull/8170/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8170&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284616 Stats: 182 lines in 10 files changed: 25 ins; 0 del; 157 mod Patch: https://git.openjdk.java.net/jdk/pull/8170.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8170/head:pull/8170 PR: https://git.openjdk.java.net/jdk/pull/8170 From sspitsyn at openjdk.java.net Fri Apr 8 22:40:40 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 8 Apr 2022 22:40:40 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. It looks good. Thank you for taking care about it. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8170 From cjplummer at openjdk.java.net Fri Apr 8 22:58:33 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 8 Apr 2022 22:58:33 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From amenkov at openjdk.java.net Sat Apr 9 00:33:39 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 9 Apr 2022 00:33:39 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. I suppose you mean NoClassDefFoundError caused by ClassNotFoundException. As far as I got recently working on similar NoClassDefFoundError issue explicitly building library is not a good idea (JTReg recommends build dependent code, but this should be done by all tests, otherwise it can cause failures of other tests). And some time ago a lot of such explicit build actions were removed from tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From amenkov at openjdk.java.net Sat Apr 9 00:42:33 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 9 Apr 2022 00:42:33 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: <6Mfg0VxYZtgueVFr2LO-w6c7gn6gQiwx4IsNtDfO1wA=.e37ab60a-ff1b-4b88-ae46-e0a11db9e03f@github.com> On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. I added evaluation in Jira ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From duke at openjdk.java.net Sat Apr 9 06:53:42 2022 From: duke at openjdk.java.net (Furkan =?UTF-8?B?w5Z6bWVu?=) Date: Sat, 9 Apr 2022 06:53:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username). Marked as reviewed by furkannzmnn at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stuefe at openjdk.java.net Sat Apr 9 06:44:53 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 9 Apr 2022 06:44:53 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke wrote: > Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: > > ``` > switch (_flags) { > case mtServiceability: > ... new BitMapFragmentTable(); break; > case mtServiceability: > ... new BitMapFragmentTable(); break; > default: ShouldNotReachHere(); > } > ``` > > Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From duke at openjdk.java.net Sun Apr 10 01:19:35 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sun, 10 Apr 2022 01:19:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/java/lang/Runnable.java line 31: > 29: * Represents an operation that does not return a result. > 30: * > 31: *

This is a functional interface This?is?supposed to?point to?the?`package?summary.html` of?`java.util.function`, so?it?should?be: Suggestion: *

This is a functional interface or Suggestion: *

This is a {@linkplain java.util.function functional interface} ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ysuenaga at openjdk.java.net Sun Apr 10 02:14:44 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 10 Apr 2022 02:14:44 GMT Subject: Integrated: 8284330: jcmd may not be able to find processes in the container In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 09:04:56 GMT, Yasumasa Suenaga wrote: > jcmd uses src/jdk.internal.jvmstat/linux/classes/sun/jvmstat/PlatformSupportImpl.java to scan temporary directories to find out processes in the container. It checks inode to ensure the temp directory is not conflicted. However inode maybe same value between the container and others. Thus we should check device id for that case. > > For example I saw following case on [distroless cc-debian11](https://github.com/GoogleContainerTools/distroless/blob/main/cc/README.md) container. I started rescue:jdk19 container with sharing PID namespace. `/proc/1/root/tmp` is different from `/tmp` on rescue:jdk19, but they are same inode value. However we can see the differense in device id. > > > $ podman run -it --rm --entrypoint=sh --pid=container:fa39662f7352 rescue:jdk19 > / # > / # stat /tmp > File: /tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: efh/239d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:51:37.000000000 > Change: 2022-04-05 08:51:37.000000000 > > / # stat /proc/1/root/tmp > File: /proc/1/root/tmp > Size: 29 Blocks: 0 IO Block: 4096 directory > Device: e1h/225d Inode: 135674931 Links: 1 > Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2022-04-05 08:51:37.000000000 > Modify: 2022-04-05 08:50:42.000000000 > Change: 2022-04-05 08:50:42.000000000 This pull request has now been integrated. Changeset: 0b867b5e Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/0b867b5e734eede768d9f6402a309208084fd044 Stats: 46 lines in 1 file changed: 26 ins; 10 del; 10 mod 8284330: jcmd may not be able to find processes in the container Reviewed-by: kevinw, iklam, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8103 From kim.barrett at oracle.com Sun Apr 10 12:34:40 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 10 Apr 2022 12:34:40 +0000 Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v6] In-Reply-To: References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: > On Apr 9, 2022, at 2:44 AM, Thomas Stuefe wrote: > > On Fri, 8 Apr 2022 17:34:57 GMT, Roman Kennke wrote: > >> Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: >> >> ``` >> switch (_flags) { >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> default: ShouldNotReachHere(); >> } >> ``` >> >> Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. > > I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. > > I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. While working on something else I ran into a similar problem and found a different approach that seemed to work well. I?m planning to explore it in the context of CHeapObj, but haven?t gotten around to it yet. I should file an RFE in case someone else is interested. From ihse at openjdk.java.net Sun Apr 10 22:18:42 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Sun, 10 Apr 2022 22:18:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81: > 79: Constructor ctor; > 80: try { > 81: Class exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException"); Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Mon Apr 11 05:15:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 05:15:30 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. Seems quite reasonable. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8106 From dholmes at openjdk.java.net Mon Apr 11 05:41:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 05:41:40 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. I agree with Alex's evaluation - this really needs fixing when the test adds an explicit `@compile` that causes the breakage. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From alanb at openjdk.java.net Mon Apr 11 06:45:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 06:45:39 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. The issue with RedefineClassTest throwing NoClassDefFoundError: jdk/test/lib/InMemoryJavaCompiler seems to go back to 2016 at least. We've had issues in other areas in the past that stemmed from implicit compilation so I assume this is what is suspected here too. In the loom repo, two of the existing RedefineClasss* classes have an explicit `@compile` because the updated tests needed to be compiled with `--enable-preview`. I would be surprised if this caused an issue but maybe it creates an issue with concurrent test execution when tests that depend on implicit compilation are running at the same time (in another agentvm) but doing explicit compilation? I wonder if creating a TEST.properties with `exclusiveAccess.dirs=.` would help this area. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From alanb at openjdk.java.net Mon Apr 11 07:16:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:16:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Sun, 10 Apr 2022 00:40:02 GMT, ExE Boss wrote: > This?is?supposed to?point to?the?`package?summary.html` Thanks, this link is indeed wrong. Will be fixed when we refresh. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 11 07:16:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:16:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Sun, 10 Apr 2022 22:14:41 GMT, Magnus Ihse Bursie wrote: > Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) The exception is in an incubator module, it's just that code in java.base can't statically reference it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Mon Apr 11 07:25:33 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 07:25:33 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> References: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> Message-ID: On Mon, 11 Apr 2022 06:41:54 GMT, Alan Bateman wrote: >> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" >> >> It is not a loom specific bug, it might happen in jdk/jdk also. >> >> The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. >> >> Also fix inlcudes some text refactoring to make push from loom smaller. > > The issue with RedefineClassTest throwing NoClassDefFoundError: jdk/test/lib/InMemoryJavaCompiler seems to go back to 2016 at least. We've had issues in other areas in the past that stemmed from implicit compilation so I assume this is what is suspected here too. > > In the loom repo, two of the existing RedefineClasss* classes have an explicit `@compile` because the updated tests needed to be compiled with `--enable-preview`. I would be surprised if this caused an issue but maybe it creates an issue with concurrent test execution when tests that depend on implicit compilation are running at the same time (in another agentvm) but doing explicit compilation? I wonder if creating a TEST.properties with `exclusiveAccess.dirs=.` would help this area. @AlanBateman adding the explicit compile commands to add `--enable-preview` is exactly what causes the problem. By compiling that individual file first it also compiled some testlib dependencies but puts the classes in a different place. When another class is later compiled, the compilation path includes that destination and so compilation succeeds, but at runtime the path is different and we get the NCDFE. This is the analysis that Alex did in a similar issue - see his comment in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From duke at openjdk.java.net Mon Apr 11 07:36:47 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 11 Apr 2022 07:36:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 07:12:09 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/StructureViolationExceptions.java line 81: >> >>> 79: Constructor ctor; >>> 80: try { >>> 81: Class exClass = Class.forName("jdk.incubator.concurrent.StructureViolationException"); >> >> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) > >> Should this not be `jdk.internal.misc`? (Also, if this is the case, maybe there's a test missing that could have discovered this...) > > The exception is in an incubator module, it's just that code in java.base can't statically reference it. Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`). It?should?probably also?be?cached. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 11 07:43:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:43:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 07:33:20 GMT, ExE Boss wrote: > Maybe it?should?use a?`MethodHandle` fetched?using `IMPL_LOOKUP` instead, in?order to?avoid the?runtime?overhead of?going through `CallerSensitive` methods (`Class.forName` and?`Constructor.newInstance`). > > It?should?probably also?be?cached. It is cached. It's also a very exceptional case that only arises when the SC API (separate JEP, not here) is used incorrectly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 11 07:55:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 11 Apr 2022 07:55:33 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> References: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> Message-ID: On Mon, 11 Apr 2022 06:41:54 GMT, Alan Bateman wrote: >> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" >> >> It is not a loom specific bug, it might happen in jdk/jdk also. >> >> The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. >> >> Also fix inlcudes some text refactoring to make push from loom smaller. > > The issue with RedefineClassTest throwing NoClassDefFoundError: jdk/test/lib/InMemoryJavaCompiler seems to go back to 2016 at least. We've had issues in other areas in the past that stemmed from implicit compilation so I assume this is what is suspected here too. > > In the loom repo, two of the existing RedefineClasss* classes have an explicit `@compile` because the updated tests needed to be compiled with `--enable-preview`. I would be surprised if this caused an issue but maybe it creates an issue with concurrent test execution when tests that depend on implicit compilation are running at the same time (in another agentvm) but doing explicit compilation? I wonder if creating a TEST.properties with `exclusiveAccess.dirs=.` would help this area. > @AlanBateman adding the explicit compile commands to add `--enable-preview` is exactly what causes the problem. By compiling that individual file first it also compiled some testlib dependencies but puts the classes in a different place. When another class is later compiled, the compilation path includes that destination and so compilation succeeds, but at runtime the path is different and we get the NCDFE. This is the analysis that Alex did in a similar issue - see his comment in JBS. Adding `--enable-preview` did not intentionally mean to introduce implicit compilation but it looks like we'll have to re-visit the ordering (as @alexmenkov suggests) in the loom repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From rkennke at openjdk.java.net Mon Apr 11 11:55:33 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 11:55:33 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Add some basic tests for ObjectBitSet ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7964/files - new: https://git.openjdk.java.net/jdk/pull/7964/files/9ea51d78..b2d913b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7964&range=06-07 Stats: 66 lines in 1 file changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7964/head:pull/7964 PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Mon Apr 11 12:05:30 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 12:05:30 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: <7Yp8cUNVVqIC0wjJukhd5zQPu4UKJbW2BrExokwzllA=.ea44e9cc-8afc-47fa-bffa-0e5882ec70b0@github.com> Message-ID: On Sat, 9 Apr 2022 06:41:11 GMT, Thomas Stuefe wrote: >>> On Apr 9\, 2022\, at 2\:44 AM\, Thomas Stuefe \ wrote\: >>> >>> On Fri\, 8 Apr 2022 17\:34\:57 GMT\, Roman Kennke \ wrote\: >>> >>>> Yes\, I get that\. But the fragments and fragment\-table are themselves inner classes that take a MEMFLAGS template\. I could \(perhaps\) either use a constexpr MEMFLAGS arg and pass this through\, or do at some point a switch like\: >>>> >>>> \`\`\` >>>> switch \(\_flags\) \{ >>>> case mtServiceability\: >>>> \.\.\. new BitMapFragmentTable\\(\)\; break\; >>>> case mtServiceability\: >>>> \.\.\. new BitMapFragmentTable\\(\)\; break\; >>>> default\: ShouldNotReachHere\(\)\; >>>> \} >>>> \`\`\` >>>> >>>> Which seems kinda\-ugly but would work \(I think\)\, and avoid making the outer class template\-ized\. >>> >>> I see what you mean\. This MEMFLAGS template parameter is deeply interwoven into everything\. I\'d just live with the current solution\. It uses established pattern\, so at least nobody is surprised\. >>> >>> I think the basic problem is that CHeapObj itself is a template class\. Rethinking MEMFLAGS seems worthwhile for a future RFE\. As I wrote\, one approach could be to make them a property of the current thread\, and switchable and stackable via a Mark class\. That way\, everything allocated within a given range of frames would count toward a given category\. No need to decide on a fine\-granular basis\. No need for templates\. Maybe no need even to have a MEMFLAGS argument for every allocation\. >> >> While working on something else I ran into a similar problem and found a different >> approach that seemed to work well\. I\?m planning to explore it in the context of >> CHeapObj\, but haven\?t gotten around to it yet\. I should file an RFE in case someone >> else is interested\. > >> Yes, I get that. But the fragments and fragment-table are themselves inner classes that take a MEMFLAGS template. I could (perhaps) either use a constexpr MEMFLAGS arg and pass this through, or do at some point a switch like: >> >> ``` >> switch (_flags) { >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> case mtServiceability: >> ... new BitMapFragmentTable(); break; >> default: ShouldNotReachHere(); >> } >> ``` >> >> Which seems kinda-ugly but would work (I think), and avoid making the outer class template-ized. > > I see what you mean. This MEMFLAGS template parameter is deeply interwoven into everything. I'd just live with the current solution. It uses established pattern, so at least nobody is surprised. > > I think the basic problem is that CHeapObj itself is a template class. Rethinking MEMFLAGS seems worthwhile for a future RFE. As I wrote, one approach could be to make them a property of the current thread, and switchable and stackable via a Mark class. That way, everything allocated within a given range of frames would count toward a given category. No need to decide on a fine-granular basis. No need for templates. Maybe no need even to have a MEMFLAGS argument for every allocation. Have we reached a consensus that the current proposal is the way to go? If so, could you please mark the latest revision as Reviewed (again), @tstuefe and @coleenp (and whoever else feels like doing so)? I also added some basic gtests for ObjectBitSet. Please note my remark on the NULL test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From aturbanov at openjdk.java.net Mon Apr 11 12:28:50 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 11 Apr 2022 12:28:50 GMT Subject: RFR: 8284673: Collapse identical catch branches in java.management Message-ID: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". It simplifies code. Reduces duplication. Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement ------------- Commit messages: - [PATCH] Collapse identical catch branches in java.management Changes: https://git.openjdk.java.net/jdk/pull/8161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284673 Stats: 170 lines in 10 files changed: 2 ins; 115 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/8161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8161/head:pull/8161 PR: https://git.openjdk.java.net/jdk/pull/8161 From coleenp at openjdk.java.net Mon Apr 11 12:36:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 11 Apr 2022 12:36:43 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet I think this looks great and thank you for all your work resolving comments and bringing this in from the lilliput changes you were going to make. This is a big improvement imo and lets us potentially fix other problems in the jvmti tag map implementation. The template instantiation doesn't bother me. There's only 2 and it's not a big code bloat and it's the way the code has been dealing with memflags. Maybe the mechanism should be revisited, like the GC change that Kim pointed to, but I don't see the motivation to make it something different. Maybe a later RFE can propose a different mechanism for memflags in general. We picked this because we thought it was simple. Thank you for your work on this, Roman and your comments Thomas. test/hotspot/gtest/utilities/test_objectBitSet.cpp line 38: > 36: // allocate a fragement for the memory range starting at 0 and mark the first bit when passing NULL. > 37: // In the absense of any error handling, I am not sure what would possibly be a reasonable better > 38: // way to do it, though. Thanks for the comment. If it matters someday we'll have the comment.. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From stuefe at openjdk.java.net Mon Apr 11 12:43:47 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 11 Apr 2022 12:43:47 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet All good ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7964 From lkorinth at openjdk.java.net Mon Apr 11 13:53:36 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 11 Apr 2022 13:53:36 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 09:36:38 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > review updates I would like to have this change approved, or the approval of removing tracking the allocation type altogether. I do not like having this pull request open any more. The current code is not okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From rkennke at openjdk.java.net Mon Apr 11 14:54:45 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 14:54:45 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: <37wlmFUyNaJ8zPwBNjRaau9ugTNDEieR7SIVWnz0Pjs=.64f446b7-9e15-4752-9401-fa26326879db@github.com> On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet Thank you all! GHA are green too, so I'll ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From rkennke at openjdk.java.net Mon Apr 11 14:54:46 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 11 Apr 2022 14:54:46 GMT Subject: Integrated: 8283710: JVMTI: Use BitSet for object marking In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 20:10:32 GMT, Roman Kennke wrote: > JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. > > In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. > > JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 > - [x] serviceability/jvmti > - [x] vmTestbase/nsk/jvmti This pull request has now been integrated. Changeset: abfd2f98 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/abfd2f98dcbe3e96efe52b1d66e4c2efb3542955 Stats: 840 lines in 13 files changed: 392 ins; 427 del; 21 mod 8283710: JVMTI: Use BitSet for object marking Reviewed-by: stuefe, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From dcubed at openjdk.java.net Mon Apr 11 16:30:02 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Apr 2022 16:30:02 GMT Subject: Integrated: 8284687: validate-source failure after JDK-8283710 Message-ID: A trivial copyright fix to solve validate-source failure after JDK-8283710. ------------- Commit messages: - 8284687: validate-source failure after JDK-8283710 Changes: https://git.openjdk.java.net/jdk/pull/8181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8181&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284687 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8181/head:pull/8181 PR: https://git.openjdk.java.net/jdk/pull/8181 From dcubed at openjdk.java.net Mon Apr 11 16:30:04 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Apr 2022 16:30:04 GMT Subject: Integrated: 8284687: validate-source failure after JDK-8283710 In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 16:21:34 GMT, Iris Clark wrote: >> A trivial copyright fix to solve validate-source failure after JDK-8283710. > > Marked as reviewed by iris (Reviewer). @irisclark - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8181 From iris at openjdk.java.net Mon Apr 11 16:30:03 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 11 Apr 2022 16:30:03 GMT Subject: Integrated: 8284687: validate-source failure after JDK-8283710 In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 16:20:02 GMT, Daniel D. Daugherty wrote: > A trivial copyright fix to solve validate-source failure after JDK-8283710. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8181 From dcubed at openjdk.java.net Mon Apr 11 16:30:05 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 11 Apr 2022 16:30:05 GMT Subject: Integrated: 8284687: validate-source failure after JDK-8283710 In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 16:20:02 GMT, Daniel D. Daugherty wrote: > A trivial copyright fix to solve validate-source failure after JDK-8283710. This pull request has now been integrated. Changeset: 470a6684 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/470a66840cda88d3be07f2b7c4c164c3265603e1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8284687: validate-source failure after JDK-8283710 Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/8181 From dfuchs at openjdk.java.net Mon Apr 11 17:31:01 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 11 Apr 2022 17:31:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/java/io/BufferedReader.java line 101: > 99: */ > 100: public BufferedReader(Reader in, int sz) { > 101: Objects.requireNonNull(in); Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true, untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Mon Apr 11 19:51:45 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 11 Apr 2022 19:51:45 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: <6Mfg0VxYZtgueVFr2LO-w6c7gn6gQiwx4IsNtDfO1wA=.e37ab60a-ff1b-4b88-ae46-e0a11db9e03f@github.com> References: <6Mfg0VxYZtgueVFr2LO-w6c7gn6gQiwx4IsNtDfO1wA=.e37ab60a-ff1b-4b88-ae46-e0a11db9e03f@github.com> Message-ID: On Sat, 9 Apr 2022 00:39:46 GMT, Alex Menkov wrote: >> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" >> >> It is not a loom specific bug, it might happen in jdk/jdk also. >> >> The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. >> >> Also fix inlcudes some text refactoring to make push from loom smaller. > > I added evaluation in Jira @alexmenkov, @dholmes-ora, @AlanBateman Thank you for your comments. I am withdrawing this PR and fix it in loom properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From lmesnik at openjdk.java.net Mon Apr 11 19:51:45 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 11 Apr 2022 19:51:45 GMT Subject: Withdrawn: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote: > The tests serviceability/jvmti/RedefineClasses start failing in loom-repo with CNFE like "java.lang.NoClassDefFoundError: jdk/test/lib/compiler/InMemoryJavaCompiler" > > It is not a loom specific bug, it might happen in jdk/jdk also. > > The workaround is to build some classes explicitly. The fix was implemented in repo-loom in Nov 2021 and there was no such failure after the fix in the loom repo. > > Also fix inlcudes some text refactoring to make push from loom smaller. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From dholmes at openjdk.java.net Mon Apr 11 22:41:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 22:41:45 GMT Subject: RFR: 8269537: memset() is called after operator new [v4] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 13:50:49 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> review updates > > I would like to have this change approved, or the approval of removing tracking the allocation type altogether. I do not like having this pull request open any more. The current code is not okay. @lkorinth it is not clear what state this PR is in as you have a merge-conflict with mainline that has not been addressed. I suggest updating the PR so it is ready to integrate again and then resume the review. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From dholmes at openjdk.java.net Mon Apr 11 23:44:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 11 Apr 2022 23:44:46 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote: >> JVMTI heap walking marks objects in order to track which have been visited already. In order to do that, it uses bits in the object header. Those are the same bits that are also used by some GCs to mark objects (the lowest two bits, also used by locking code). Some GCs also use the bits in order to indicate 'forwarded' objects, where the upper bits of the header represent the forward-pointer. In the case of Shenandoah, it's even more problematic because this happens concurrently, even while JVMTI heap walks can intercept. So far we carefully worked around that problem, but it becomes very problematic in Lilliput, where accesses to the Klass* also requires to decode the header, and figure out what bits means what. >> >> In addition to that, marking objects in their header requires that the original header gets saved and restored. We only do that for 'interesting' headers, that is headers that have a stack-lock, monitor or hash-code. All other headers are reset to their default value. This means we are losing object's GC age. This is not catastrophic, but nontheless interferes with GC. >> >> JFR already has a datastructure called BitSet to support object marking without messing with object's headers. We can use that in JVMTI too. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] serviceability/jvmti >> - [x] vmTestbase/nsk/jvmti > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Add some basic tests for ObjectBitSet src/hotspot/share/jfr/leakprofiler/chains/jfrbitset.hpp line 26: > 24: > 25: #ifndef SHARE_JFR_LEAKPROFILER_JFRBITMAP_HPP > 26: #define SHARE_JFR_LEAKPROFILER_JFRBITMAP_HPP This is wrong - it should be BITSET not BITMAP ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From cjplummer at openjdk.java.net Tue Apr 12 00:21:36 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 12 Apr 2022 00:21:36 GMT Subject: RFR: 8284673: Collapse identical catch branches in java.management In-Reply-To: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement Marked as reviewed by cjplummer (Reviewer). src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java line 1198: > 1196: throw new RuntimeOperationsException(ree, > 1197: "RuntimeException occurred in RequiredModelMBean "+ > 1198: "while trying to invoke operation " + opName); This one is a bit different. You've collapsed RuntimeOperationsException into the RuntimeException handler, which seems fine since it is a subclass of RuntimeException and both handlers do the same thing. However, I wonder if the original intent of the RuntimeOperationsException handler was for it to have a different message, and perhaps reference RuntimeOperationsException instead of RuntimeException. ------------- PR: https://git.openjdk.java.net/jdk/pull/8161 From dholmes at openjdk.java.net Tue Apr 12 01:52:38 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 01:52:38 GMT Subject: RFR: 8284673: Collapse identical catch branches in java.management In-Reply-To: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement Nice cleanup! Great to see the code duplication gone. One minor additional edit requested below. Thanks, David src/java.management/share/classes/javax/management/relation/RelationService.java line 1920: > 1918: } catch (InstanceNotFoundException | ReflectionException exc1) { > 1919: throw new RuntimeException(exc1.getMessage()); > 1920: } catch (MBeanException exc3) { Please change exc3 to exc2 ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8161 From dholmes at openjdk.java.net Tue Apr 12 01:52:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Apr 2022 01:52:39 GMT Subject: RFR: 8284673: Collapse identical catch branches in java.management In-Reply-To: References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: On Tue, 12 Apr 2022 00:12:42 GMT, Chris Plummer wrote: >> Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". >> It simplifies code. Reduces duplication. >> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement > > src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java line 1198: > >> 1196: throw new RuntimeOperationsException(ree, >> 1197: "RuntimeException occurred in RequiredModelMBean "+ >> 1198: "while trying to invoke operation " + opName); > > This one is a bit different. You've collapsed RuntimeOperationsException into the RuntimeException handler, which seems fine since it is a subclass of RuntimeException and both handlers do the same thing. However, I wonder if the original intent of the RuntimeOperationsException handler was for it to have a different message, and perhaps reference RuntimeOperationsException instead of RuntimeException. The proposed change is behaviour preserving so I have no issue with it. If something else was intended then that would be a new RFE IMO. ------------- PR: https://git.openjdk.java.net/jdk/pull/8161 From ecki at zusammenkunft.net Tue Apr 12 02:02:23 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 12 Apr 2022 02:02:23 +0000 Subject: RFR: 8284673: Collapse identical catch branches in java.management In-Reply-To: References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: Hello, > new RuntimeException(exc1.getMessage()) I typically try to avoid swallowing the cause and especially the exception type of a inner exception, especially in this case where two different exceptions are caught. Better do tostring() and/or specify the exception as a cause to have chaining? -- https://bernd.eckenfels.net ________________________________ From: serviceability-dev on behalf of David Holmes Sent: Tuesday, April 12, 2022 3:52:38 AM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: 8284673: Collapse identical catch branches in java.management On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement Nice cleanup! Great to see the code duplication gone. One minor additional edit requested below. Thanks, David src/java.management/share/classes/javax/management/relation/RelationService.java line 1920: > 1918: } catch (InstanceNotFoundException | ReflectionException exc1) { > 1919: throw new RuntimeException(exc1.getMessage()); > 1920: } catch (MBeanException exc3) { Please change exc3 to exc2 ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8161 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iklam at openjdk.java.net Tue Apr 12 05:31:38 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 12 Apr 2022 05:31:38 GMT Subject: RFR: 8284616: Implement workaround for CODETOOLS-7901986 in serviceability/jvmti/RedefineClasses In-Reply-To: References: <7p54zH5Ws20WRAh7w9k-WXQAZVS-oaPzy1q0yCjuphU=.9b1b875d-ac10-4505-a484-ff275dfaec5a@github.com> Message-ID: On Mon, 11 Apr 2022 07:52:34 GMT, Alan Bateman wrote: > > @AlanBateman adding the explicit compile commands to add `--enable-preview` is exactly what causes the problem. By compiling that individual file first it also compiled some testlib dependencies but puts the classes in a different place. When another class is later compiled, the compilation path includes that destination and so compilation succeeds, but at runtime the path is different and we get the NCDFE. This is the analysis that Alex did in a similar issue - see his comment in JBS. > > Adding `--enable-preview` did not intentionally mean to introduce implicit compilation but it looks like we'll have to re-visit the ordering (as @alexmenkov suggests) in the loom repo. I believe the underlying cause of this type of failure is https://bugs.openjdk.java.net/browse/CODETOOLS-7902847 "Class directory of a test case should not be used to compile a library" You can easily see the bug by adding this to test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.java in the mainline JDK repo: + * @compile RedefineRunningMethods.java * @run main RedefineClassHelper Clean up your jtreg "work" directory and run this test by itself. Afterwards, look for .class files in the jtreg work dir: ./work/classes/test/lib/RedefineClassHelper.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineRunningMethods.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineRunningMethods$2.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/compiler/InMemoryJavaCompiler$FileManagerWrapper$1.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/compiler/InMemoryJavaCompiler$FileManagerWrapper.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/compiler/InMemoryJavaCompiler$MemoryJavaFileObject.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/compiler/InMemoryJavaCompiler.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/helpers/ClassFileInstaller$Manifest.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/jdk/test/lib/helpers/ClassFileInstaller.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineRunningMethods$1.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineRunningMethods$3.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineClassHelper.class ./work/classes/serviceability/jvmti/RedefineClasses/RedefineRunningMethods.d/RedefineRunningMethods_B.class You can see that the `@library /test/lib` is split into two parts: /work/classes/test/lib/ - Most of it is in the directory that's used only by the RedefineRunningMethods.java test case - Some of it is in the `work/classes/test/lib/` directory, which is shared by all test cases. Now, create a test case RedefineRunningMethods2.java in the same directory that looks like this: /* * @test * @requires vm.jvmti * @library /test/lib * @modules java.base/jdk.internal.misc * @modules java.compiler * java.instrument * jdk.jartool/sun.tools.jar * @run main RedefineClassHelper */ If you run these two test together, RedefineRunningMethods.java is executed first, leaving the work directory in the same condition as shown above. Then, jtreg runs RedefineRunningMethods2.java, and sees `work/classes/test/lib/RedefineClassHelper.class` is already there. So it executes RedefineClassHelper without rebuilding it, leading to a failure because classes that RedefineClassHelper depends on are not available to this second test. I have a very simple reproducer in the bug above with a detailed log that shows what is happening. While this problem could be worked around, I believe the right fix should be done inside jtreg. ------------- PR: https://git.openjdk.java.net/jdk/pull/8170 From rkennke at openjdk.java.net Tue Apr 12 06:11:46 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Apr 2022 06:11:46 GMT Subject: RFR: 8283710: JVMTI: Use BitSet for object marking [v8] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 23:41:40 GMT, David Holmes wrote: > This is wrong - it should be BITSET not BITMAP Oh, good find! I filed a follow-up issue: https://bugs.openjdk.java.net/browse/JDK-8284725 ------------- PR: https://git.openjdk.java.net/jdk/pull/7964 From aturbanov at openjdk.java.net Tue Apr 12 07:46:28 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 12 Apr 2022 07:46:28 GMT Subject: RFR: 8284673: Collapse identical catch branches in java.management [v2] In-Reply-To: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284673: Collapse identical catch branches in java.management rename exc3 to exc2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8161/files - new: https://git.openjdk.java.net/jdk/pull/8161/files/2dd8a18b..b6940625 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8161&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8161&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8161/head:pull/8161 PR: https://git.openjdk.java.net/jdk/pull/8161 From alanb at openjdk.java.net Tue Apr 12 13:05:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 12 Apr 2022 13:05:33 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 17:27:11 GMT, Daniel Fuchs wrote: > Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From djelinski at openjdk.java.net Tue Apr 12 16:52:54 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 16:52:54 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/sun/nio/ch/SelChImpl.java line 89: > 87: } else { > 88: long millis; > 89: if (nanos == 0) { Was this change intentional? (`<=` replaced by `==`) If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From djelinski at openjdk.java.net Tue Apr 12 19:12:48 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Apr 2022 19:12:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110: > 108: > 109: public void flushBuffer() throws IOException { > 110: if (lock instanceof InternalLock locker) { now that StreamEncoder is final, we can drop the `else` branch ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Wed Apr 13 09:52:13 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 13 Apr 2022 09:52:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> On Tue, 12 Apr 2022 13:02:44 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/BufferedReader.java line 101: >> >>> 99: */ >>> 100: public BufferedReader(Reader in, int sz) { >>> 101: Objects.requireNonNull(in); >> >> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. >> Now that I think of it - it probably does matter since even if CAN_USE_INTERNAL_LOCK is true, untrusted subclasses of BufferedReader calling this constructor might expect the locking to be performed on `in`? > >> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. > > Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. Thanks - the same issue appears with `BufferedWriter`/`Writer`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Wed Apr 13 11:53:23 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 13 Apr 2022 11:53:23 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> References: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> Message-ID: On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs wrote: >>> Not sure if that even matters - but there will be a slight change of behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`. Instead of synchronizing on `in`, the `BufferedReader` will synchronize on `this`. >> >> Good! We can change this so that depends on whether BufferedReader is extended and whether the given Reader is trusted. It's not clear if anyone could reliably depend on undocumented behavior like this but we have to be cautious at the same time. > > Thanks - the same issue appears with `BufferedWriter`/`Writer`. The?solution is?to?add the?`private`?constructor: private Reader(Object fallbackLock, Void internal) { // assert fallbackLock != null; // use InternalLock for trusted classes Class clazz = getClass(); if (clazz == InputStreamReader.class || clazz == BufferedReader.class || clazz == FileReader.class || clazz == sun.nio.cs.StreamDecoder.class) { this.lock = InternalLock.newLockOr(fallbackLock); } else { this.lock = fallbackLock; } } to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`). --- The?`protected`?`Reader`?constructors can?then be?changed to: protected Reader() { this(this, null); } and protected Reader(Object lock) { this(Objects.requireNonNull(lock), null); } --- Doing?so will?allow this?change to?be?reverted: Suggestion: super(in); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Wed Apr 13 11:53:27 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 13 Apr 2022 11:53:27 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> On Tue, 12 Apr 2022 19:09:32 GMT, Daniel Jeli?ski wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > src/java.base/share/classes/sun/nio/cs/StreamEncoder.java line 110: > >> 108: >> 109: public void flushBuffer() throws IOException { >> 110: if (lock instanceof InternalLock locker) { > > now that StreamEncoder is final, we can drop the `else` branch Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` (which?it might?be if?it gets?exposed as?a?system?property). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 12:02:16 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 12:02:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> References: <0jpZ1dprNSBX81zrd455SGK5Z_vvp5EtT5oS8b-XLxE=.adac88d9-cef5-479b-b94d-2de4cf381909@github.com> Message-ID: <42x8p2tSXc1XsNqEQV1xTKhIfg9RBPLMiY2YQOwkS_Q=.25eb38fd-d338-49b5-a0aa-240043062f7b@github.com> On Tue, 12 Apr 2022 16:49:41 GMT, Daniel Jeli?ski wrote: > If it was, please update the javadoc - `NANOSECONDS.toMillis(-1)` = 0 implies no waiting in Net.poll It's benign for the current usages but you are right, it was not intentional. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 14:21:20 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:21:20 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: Message-ID: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/21972f45..0e12c206 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=00-01 Stats: 1837 lines in 112 files changed: 786 ins; 531 del; 520 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 14:22:18 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:22:18 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> References: <4-uBO0InSz17RTM1s27E5N7wWALqT4QnQDEqaC1Msbk=.4864c9fe-caeb-4eb6-aaaf-1ac5695049c6@github.com> Message-ID: On Wed, 13 Apr 2022 11:35:33 GMT, ExE Boss wrote: > Actually, we?can?t in?case `InternalLock.CAN_USE_INTERNAL_LOCK` is?ever?`false` That's right, both StreamEncoder and StreamDecoder need the both cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 13 14:59:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 13 Apr 2022 14:59:32 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <0TWk5zeiftA1QMeIsGcHifCZ2qSb30DiHmheGwMK64s=.85193997-2184-42bc-a65b-b14fb6ccd2af@github.com> Message-ID: On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss wrote: >> Thanks - the same issue appears with `BufferedWriter`/`Writer`. > > The?solution is?to?add the?`private`?constructor: > > private Reader(Object fallbackLock, Void internal) { > // assert fallbackLock != null; > // use InternalLock for trusted classes > Class clazz = getClass(); > if (clazz == InputStreamReader.class > || clazz == BufferedReader.class > || clazz == FileReader.class > || clazz == sun.nio.cs.StreamDecoder.class) { > this.lock = InternalLock.newLockOr(fallbackLock); > } else { > this.lock = fallbackLock; > } > } > > to?`Reader` (and?an?equivalent `private`?constructor to?`Writer`). > > --- > > The?`protected`?`Reader`?constructors can?then be?changed to: > > protected Reader() { > this(this, null); > } > > and > > protected Reader(Object lock) { > this(Objects.requireNonNull(lock), null); > } > > > --- > > Doing?so will?allow this?change to?be?reverted: > Suggestion: > > super(in); > Thanks - the same issue appears with `BufferedWriter`/`Writer`. Right. I think we can reduce this to the case where a BufferedReader is not subclassed, and it wraps an InputStreamReader or FileReader that have not been subclassed. Similarly the case where a BufferedWriter is not subclassed and it wraps an OutputStreamWriter or FileWriter that have not been subclassed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Wed Apr 13 15:02:36 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:02:36 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing Message-ID: Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. _Thanks for @tstuefe for suggesting this._ ------------- Commit messages: - Wrap ASGCT in crash protection code Changes: https://git.openjdk.java.net/jdk/pull/8225/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284828 Stats: 144 lines in 1 file changed: 87 ins; 56 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Wed Apr 13 15:17:20 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Apr 2022 15:17:20 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ src/hotspot/share/prims/forte.cpp line 671: > 669: #ifndef ASSERT > 670: trace->num_frames = ticks_unknown_state; > 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ OIC - this is only when asserts are not enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Wed Apr 13 15:23:09 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:23:09 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ src/hotspot/share/prims/forte.cpp line 508: > 506: > 507: > 508: void asyncGetCallTraceImpl(ASGCT_CallTrace *trace, jint depth, void* ucontext) { make it static? No need to export this. src/hotspot/share/prims/forte.cpp line 669: > 667: JNIEXPORT > 668: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { > 669: #ifndef ASSERT Since ThreadCrashProtection uses Thread::current, here I would bail for Thread::current_or_null_safe() == NULL src/hotspot/share/prims/forte.cpp line 674: > 672: os::ThreadCrashProtection crash_protection; > 673: if (!crash_protection.call(cb)) { > 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { Where does this -10 come from? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Wed Apr 13 15:23:10 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:23:10 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:11:41 GMT, Jaroslav Bachorik wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > src/hotspot/share/prims/forte.cpp line 671: > >> 669: #ifndef ASSERT >> 670: trace->num_frames = ticks_unknown_state; >> 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); > > ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ > > OIC - this is only when asserts are not enabled. I think if we start using ThreadCrashProtection like a general-purpose class, we should make it one and remove the JFR dependencies. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Wed Apr 13 15:35:26 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 13 Apr 2022 15:35:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ I'm actually ambivalent about the "production only" thing. I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. Optionally, I'd make the behavior of ThreadCrashProtection switchable at runtime with a diagnostic XX switch. That switch would control the jumping back in the signal handler. That way, if you encounter strange bugs while using async profiler, one can disable the crash guard and enable asserts and crashes. If you decide to do that, we should also do tests for it, so maybe leave it for a future RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:35:29 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:35:29 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:19:43 GMT, Thomas Stuefe wrote: >> src/hotspot/share/prims/forte.cpp line 671: >> >>> 669: #ifndef ASSERT >>> 670: trace->num_frames = ticks_unknown_state; >>> 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); >> >> ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ >> >> OIC - this is only when asserts are not enabled. > > I think if we start using ThreadCrashProtection like a general-purpose class, we should make it one and remove the JFR dependencies. I fully agree, should I do this as part of this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:46 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:46 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: References: Message-ID: <2EvIrXO3KCfYDt1_O5tkJRAwvxik7E1yj98cE8UK6ls=.23cce809-aae8-48da-95d3-c2a162768b26@github.com> > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Check for Thread::current_or_null_safe and other stuff ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/4b5f34c6..80d227cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:48 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:48 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> References: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> Message-ID: On Wed, 13 Apr 2022 15:18:15 GMT, Thomas Stuefe wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for Thread::current_or_null_safe and other stuff > > src/hotspot/share/prims/forte.cpp line 674: > >> 672: os::ThreadCrashProtection crash_protection; >> 673: if (!crash_protection.call(cb)) { >> 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { > > Where does this -10 come from? it is the lowest error code ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:41:49 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:41:49 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v2] In-Reply-To: References: <0sKTrq19b1zQ9EWEXIZlVbj008SJiu3OcIKBQCgOEwc=.cde5895d-63b5-48df-a7fe-79eaccc911b0@github.com> Message-ID: On Wed, 13 Apr 2022 15:36:05 GMT, Johannes Bechberger wrote: >> src/hotspot/share/prims/forte.cpp line 674: >> >>> 672: os::ThreadCrashProtection crash_protection; >>> 673: if (!crash_protection.call(cb)) { >>> 674: if (trace->num_frames < -10 || trace->num_frames >= 0) { >> >> Where does this -10 come from? > > it is the lowest error code I removed it, an invalid error code should never happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:47:08 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:47:08 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v3] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Turn it always on ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/80d227cd..d3a66505 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Wed Apr 13 15:47:08 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 13 Apr 2022 15:47:08 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > I'm actually ambivalent about the "production only" thing. > > I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. > > Optionally, I'd make the behavior of ThreadCrashProtection switchable at runtime with a diagnostic XX switch. That switch would control the jumping back in the signal handler. That way, if you encounter strange bugs while using async profiler, one can disable the crash guard and enable asserts and crashes. If you decide to do that, we should also do tests for it, so maybe leave it for a future RFE. What @tstuefe said about debug vs. production made me wonder whether the assert in `ThreadCrashProtection` is still useful at all. I mean, we are deliberately using it from threads other than the JFR sampler thread and if that usage is not breaking stuff left and right, probably we could remove it? (/cc @mgronlun) ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:47:09 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:47:09 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 15:29:00 GMT, Thomas Stuefe wrote: > I dislike having different behavior between debug and release, I prefer to test what later runs in the field. Also, if we prevent crashes because we want to ignore them, we should ignore them in debug too, otherwise, we burn error analysis cycles needlessly. I copied this from JFR (where this the default, albeit configurable behaviour). But I agree and changed it. > What @tstuefe said about debug vs. production made me wonder whether the assert in ThreadCrashProtection is still useful at all. I mean, we are deliberately using it from threads other than the JFR sampler thread and if that usage is not breaking stuff left and right, probably we could remove it? I agree, I'm going to remove it. Its functionality is too good to be restrained to JFR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 15:55:52 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 15:55:52 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: Message-ID: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove JFR assert from ThreadCrashProtection Remove the Thread::is_JfrSampler_thread() method too, as it has only be used by the removed asserts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/d3a66505..77a21cb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=02-03 Stats: 9 lines in 6 files changed: 1 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 13 16:57:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 13 Apr 2022 16:57:16 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts I would like to add an `-XX` option to disable the crash protection for testing. But I don't know how to do this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From mgronlun at openjdk.java.net Wed Apr 13 16:57:15 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Apr 2022 16:57:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts The JFR code has the product vs debug split in order to capture - debug and fix - the issues in stack walking that we protect for in product builds. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aturbanov at openjdk.java.net Wed Apr 13 17:52:19 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Apr 2022 17:52:19 GMT Subject: Integrated: 8284673: Collapse identical catch branches in java.management In-Reply-To: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> References: <34pNgGZG2T36UhnpWhnc5AcceFO7benSN6YwcATm4Fk=.27e3d673-dd9d-45bb-90e5-2bc944b57177@github.com> Message-ID: On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote: > Let's take advantage of Java 7 language feature - "Catching Multiple Exception Types". > It simplifies code. Reduces duplication. > Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try' statement This pull request has now been integrated. Changeset: 249d54f9 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/249d54f93da8dae0cd24c53dfca751a8627aaf1f Stats: 172 lines in 10 files changed: 2 ins; 115 del; 55 mod 8284673: Collapse identical catch branches in java.management Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8161 From aturbanov at openjdk.java.net Wed Apr 13 20:45:35 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 13 Apr 2022 20:45:35 GMT Subject: RFR: 8284853: Fix varios 'expected' typo Message-ID: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. ------------- Commit messages: - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo - [PATCH] Fix 'expected' typo Changes: https://git.openjdk.java.net/jdk/pull/8231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284853 Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From bpb at openjdk.java.net Wed Apr 13 22:15:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 13 Apr 2022 22:15:15 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Expect the Unexpeted. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From cjplummer at openjdk.java.net Wed Apr 13 22:45:18 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 13 Apr 2022 22:45:18 GMT Subject: RFR: 8284853: Fix varios 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. test/jdk/java/lang/StackWalker/StackStreamTest.java line 218: > 216: private static void equalsOrThrow(String label, List list, List expected) { > 217: System.out.println("List: " + list); > 218: System.out.println("Expected: " + list); I think there is a per-existing bug here. Shouldn't the second println print `expected` instead of `list`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From jbachorik at openjdk.java.net Thu Apr 14 06:17:04 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 06:17:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts As for the `-XX` option - I think you can start from [globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp). ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 06:17:04 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 06:17:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts and how I can I access it from the code deep down? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Thu Apr 14 06:54:15 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 06:54:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: <0kBSFmTMFv0M-bnpTMtjnSccc2FChAW4vZ9XwwKq1Ro=.ac14378a-ffbe-4efd-bd57-cbe84a6c581f@github.com> On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts Should be as easy as eg. https://github.com/openjdk/jdk/blob/bf85b0095ff3ad8775501bd65e7ccf9103ecc15f/src/hotspot/share/runtime/os.cpp#L463 - where `ReduceSignalUsage` is defined as https://github.com/openjdk/jdk/blob/bf85b0095ff3ad8775501bd65e7ccf9103ecc15f/src/hotspot/share/runtime/globals.hpp#L722 ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aturbanov at openjdk.java.net Thu Apr 14 09:28:17 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 09:28:17 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8284853: Fix various 'expected' typo improve test log ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8231/files - new: https://git.openjdk.java.net/jdk/pull/8231/files/fe6d9890..9fc75e89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8231&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8231/head:pull/8231 PR: https://git.openjdk.java.net/jdk/pull/8231 From luhenry at openjdk.java.net Thu Apr 14 10:20:11 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Thu, 14 Apr 2022 10:20:11 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts At https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461, you have a NoHandleMark which wouldn?t get cleaned up in case of crash. For other such cases, it could be worth having some form of assertion in StackObj destructor to make sure you don?t call it when you have a crash protection. That assert would trigger only in debug and even when there is no crash so it should help us root out such issue faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From yyang at openjdk.java.net Thu Apr 14 10:42:11 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 14 Apr 2022 10:42:11 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From stuefe at openjdk.java.net Thu Apr 14 11:11:17 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 11:11:17 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 10:16:28 GMT, Ludovic Henry wrote: > At > > https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461 > > , you have a NoHandleMark which wouldn?t get cleaned up in case of crash. > For other such cases, it could be worth having some form of assertion in StackObj destructor to make sure you don?t call it when you have a crash protection. That assert would trigger only in debug and even when there is no crash so it should help us root out such issue faster. Darn, @luhenry is right. And the more I think about this, the more doubts I get about this approach. We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? Because as long as we cannot guarantee that we really don't use RAII, or actually anything needing cleanup (e.g. dynamic memory allocation), and that we don't accidentally abandon a lock, we cannot use sigjmp. This precludes use of resource area, and had that not been an issue? We cannot even use malloc here. Under these circumstances, crashing may be better than not crashing, since not crashing could leave the thread in a corrupted state or in a deadlock. I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. Sorry for this. If I'm wrong, please someone correct me. This looked like a simple solution at first. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 11:33:15 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 11:33:15 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 11:06:50 GMT, Thomas Stuefe wrote: > We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? They share almost all of their code. Allocating on the heap is not safe in the signal handler and should be considered an error. My goal is remove all code that (potentially) modifies the heap or the state of the VM from AsyncGetCallTrace, with the focus on the methods that are called from AsyncGetCallTrace but from JFR. Both are so similar that this practical. Regarding the `NoHandleMark`: I must have missed this. > I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. They are complementary goals. My goal is to improve ASGCT and its stability but this PR should help prevent rare segmentation faults to appear in production. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 11:43:03 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 11:43:03 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v5] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Place NoHandleMark properly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/77a21cb5..8abf582c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Thu Apr 14 12:59:26 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 12:59:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4] In-Reply-To: References: <8xwsTix84l48SqTssnCpU7XBD2IasVdqIJnntlNvr3U=.e9b83bf8-ff74-4ad4-a4f6-4cae3fb3df13@github.com> Message-ID: On Thu, 14 Apr 2022 11:30:13 GMT, Johannes Bechberger wrote: > > We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? > > They share almost all of their code. Allocating on the heap is not safe in the signal handler and should be considered an error. > > My goal is remove all code that (potentially) modifies the heap or the state of the VM from AsyncGetCallTrace, with the focus on the methods that are called from AsyncGetCallTrace but from JFR. Both are so similar that this practical. > > Regarding the `NoHandleMark`: I must have missed this. > > > I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing. > > They are complementary goals. My goal is to improve ASGCT and its stability but this PR should help prevent rare segmentation faults to appear in production. Sorry, I remain unconvinced. Catching and ignoring error signals is akin to silencing the smoke detector because the noise bothers you. Your house still burns. With this patch, we would ignore error signals and the VM would continue running, with a potentially corrupted state of VM and/or system libraries. That may cause silent data corruption, or even security holes. A hard fast crash is always better. We deliberately never return from error handling for this very reason. Once we report a crash, we never even unwind the stack. There had been attempts in the past to return from error handling to normal VM mode for this reason and that, and we always avoided it. The sigjmp technique is fine if you can guarantee that your code does not change state beyond what lives on the thread stack. No global state can change then, not in the VM itself, nor in system libraries. In order to prove that your catch-all patch is safe, you would have to fine-comb AGCT and all the code it calls and make it safe to always jump out of. I believe the work involved would be much higher than just fixing the crashes, and it would be much more prone to bitrot. I believe there is no easy way here. I think if you want to make AGCT safe, you have to analyze and solve the individual crash points. Because if you catch them wholesale, how do you know which crashes are safe to ignore, and which should stop the VM? And even if the crash is safe to ignore, how do you know that by sigjumping back you won't leave the VM in an inconsistent state? ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 13:06:58 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 13:06:58 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Handle nested ThreadCrashProtection on POSIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/8abf582c..5e2be187 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=04-05 Stats: 28 lines in 3 files changed: 11 ins; 9 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From ihse at openjdk.java.net Thu Apr 14 13:13:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 13:13:15 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote: >> Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8284853: Fix various 'expected' typo > improve test log Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8231 From luhenry at openjdk.java.net Thu Apr 14 13:55:59 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Thu, 14 Apr 2022 13:55:59 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX It could be worth exploring unifying the JFR and AGCT stackwalking mechanism then. If the crash handler is good enough for JFR, it should be considered good enough for AGCT. As raised in a separate email exchange, this doesn't however fix all kind of crashes, such as calls to `guarantee(...)` (like in `CodeCache::find_blob`) since it does not trigger a signal but calls `VMError::report_and_die` directly (or equivalent). Since the code of JFR for stackunwinding is pretty much a copy/paste of AGCT, it's not clear to me what's the difference is (which locks are being held? which other synchronization mechanism?). By unifying, and making sure we use JFR's mechanism wholesale in AGCT, we would make sure AGCT is at least as stable as JFR. From our production use, JFR is stable (we haven't observe consistent crashes like we do with AGCT), so that is to me the reference we need to match. I understand the AGCT2 proposal is unifying + native frames. So we could take the unifying and make it part of this enhancement to AGCT and keep the native frames for AGCT2. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:09:04 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:09:04 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:53:08 GMT, Ludovic Henry wrote: > I understand the AGCT2 proposal is unifying + native frames. So we could take the unifying and make it part of this enhancement to AGCT and keep the native frames for AGCT2. I don't think that this should be part of this PR. I'm currently looking into the differences between ASGCT and JFR to be able to certify that ASGCT satisfies the condition of ThreadCrashProtection. If this the case then using it is not problematic. After this a unification is possible, but I would like to keep this PR simple. The unification changes far more code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From jbachorik at openjdk.java.net Thu Apr 14 14:16:45 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 14 Apr 2022 14:16:45 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: <-TeNiJLBgA5wVXx5z0gqVqCHt5tjPAw7cR7Xj1Cu_UM=.39273b82-d452-4a79-a23c-86f633203b4f@github.com> On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX I second the attitude of not snowballing on this PR. Either this is a totally hopeless approach and should be abandoned or it is ok short term and then we should proceed. If nothing else, an isolated and focused fix will have higher chances of backporting than if we just pile on all the goodies we want from the JFR/ASGCT unification (which I think will never get backported). And from the practical ponit of view we really need the chance of crashing JVM reduced in all important versions back to JDK 8 - I know users should upgrade but there is the the nice, theoretical world and then there is the messy world we live in where JDK 8 will continue on living for at least a few years and we (Datadog) need to support it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:37:25 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:37:25 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v7] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add CrashProtectAsyncGetCallTrace option ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/5e2be187..d003ce09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=05-06 Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:37:26 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:37:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 13:06:58 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Handle nested ThreadCrashProtection on POSIX I compared the code of ASGCT and JFR and found only one instance of a method that is used in ASGCT, but not in JFR and which does affect the VM state. It is the `JavaThread::block_if_vm_exited` method which is transitively called, a fix for this is coming. Therefore there is, in my opinion, no reason why we cannot wrap AsyncGetCallTrace in ThreadCrashProtection. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 14:56:29 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 14:56:29 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v8] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Do not call JavaThread::thread_from_jni_environment Calling JavaThread::thread_from_jni_environment for a terminated thread might cause the aquisition of a lock. Calling JavaThread::current does not have this problem and AsyncGetCallTrace can only be called on the current thread anyway. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/d003ce09..b16e85d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 15:19:17 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 15:19:17 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use JavaThread::current_or_null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8225/files - new: https://git.openjdk.java.net/jdk/pull/8225/files/b16e85d2..102fd783 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8225&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8225.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8225/head:pull/8225 PR: https://git.openjdk.java.net/jdk/pull/8225 From stuefe at openjdk.java.net Thu Apr 14 15:45:31 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 14 Apr 2022 15:45:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v6] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 14:33:35 GMT, Johannes Bechberger wrote: > I compared the code of ASGCT and JFR and found only one instance of a method that is used in ASGCT, but not in JFR and which does affect the VM state. It is the `JavaThread::block_if_vm_exited` method which is transitively called, a fix for this is coming. Therefore there is, in my opinion, no reason why we cannot wrap AsyncGetCallTrace in ThreadCrashProtection. Sorry, you did address none of my arguments. I see a reasoning chain that starts by JFR being "good enough" and from there concluding that using it in AGCT its good enough too. Well, maybe it was a bad idea in the first place. And right now, this code is only used by JFR. Reusing it perpetuates this pattern which others will follow. Because its so convenient just to catch all crashes. Does the code use Resource Area? Then its not sigjmp safe. Does it do any kind of dynamic allocation which could leak? Then its not sigjmp safe. Does it use locks? Again, not sigjmp safe. Does it use any kind of RAII objects? You guess it, its not sigjmp safe. Does it call libc functions that cause it to change state? Probably unsafe too. And even if you today can prove that the whole code is safe, how do you prevent bitrot? These are general purpose hotspot functions. Someone may tomorrow use malloc, or RA. How would you know? The fact that we never saw a problem in JFR does not prove much. A corruption may never show symptoms. It may only effect certain platforms, certain conditions, certain flukes of the memory layout god. There may be that one crash that you really should not have ignored or sigjmp'ed out of, but you never saw it in your tests, because it only happens to that one customer. What I really worry about is the delayed effect. Hiding the crash may cause delayed errors that are really hard to track down. Effectively transforming what would be a simple crash with an hs-err file and a core into a maintenance nightmare. That is why sigjmp is used very sparingly, and only in very controlled environments. Put it another way: to really prove that what you do is safe, you have to answer, for every possible crash location: 1) is the crash itself benign and can be ignored? 2) is it safe to jump out of the crash code back to the entrance of AGCT, or would that interruption corrupt the VM or a system library? My point is, if you can answer these questions, you can fix the crash. Therefore it makes no sense to wholesale catch signals. Either the code is safe and does not crash, then no need for catch-all. Or it is not, then its important to understand where we crash and why. Ignoring unknown crashes is not a good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From ihse at openjdk.java.net Thu Apr 14 16:12:27 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 16:12:27 GMT Subject: RFR: 8284891: Fix typos in build system files Message-ID: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com> I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos. (Due to false positives this can unfortunately not be run automatically) Most of the fixes are in comments. A few are in messages aimed at the user. ------------- Commit messages: - 8284891: Fix typos in build system files Changes: https://git.openjdk.java.net/jdk/pull/8246/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8246&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284891 Stats: 72 lines in 46 files changed: 0 ins; 0 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/8246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8246/head:pull/8246 PR: https://git.openjdk.java.net/jdk/pull/8246 From erikj at openjdk.java.net Thu Apr 14 16:29:40 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Apr 2022 16:29:40 GMT Subject: RFR: 8284891: Fix typos in build system files In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com> References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com> Message-ID: On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > Most of the fixes are in comments. A few are in messages aimed at the user. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8246 From mgronlun at openjdk.java.net Thu Apr 14 16:47:31 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Apr 2022 16:47:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null One important difference to consider is that in JFR, in contrast to AGCT. there is only a single thread, the ThreadSampler thread, that is wrapped in the CrashProtection. Stack walking is different in JFR compared to AGCT, in that it is done by a _different_thread_, during a point where the target is suspended. Originally, this thread sampler thread was not even part of the VM, although now it is a NonJavaThread. It has been trimmed to not involve malloc(), raii, and other hard-to-recover from constructs, from the moment it has another thread suspended. Over the years, some transitive malloc() calls has snuck in, but it was eventually found due to rare deadlocking. Thomas brings a good point about crashes needing to be recoverable. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From mgronlun at openjdk.java.net Thu Apr 14 17:11:31 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Apr 2022 17:11:31 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null For additional context, I should add that the CrashProtection mechanism was mainly put in place as a result of having to deliver JFR from JRockit into Hotspot under a deadline. upholding feature-parity. The stack walking code was in really bad shape back then. Over the years though, it has been hardened and improved much, and I have not seen any reported issues about JFR crashes in many years (we log when crashing in production). An important difference is that AGCT allows more thread states compared to JFR, so there can be issues in that area that are not seen in JFR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Thu Apr 14 17:41:30 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 14 Apr 2022 17:41:30 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: <3F_-XP2apC9QBGJ8O1UUpnoWvJJLd1ZblXocwm7cBUk=.ca5329a6-32ab-4803-9fdb-7e4defec92cc@github.com> On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null This seems to get a bit out of hand and I do not currently have time to address these (vacation). I would like to put the discussion on hold for now and therefore converted it into a draft. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From aturbanov at openjdk.java.net Thu Apr 14 18:09:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:34 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 10:38:33 GMT, Yi Yang wrote: >I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948), I wonder if you can merge this into your patch so that I do not need to submit a new PR for it? Thanks. I think it deserves a separate ticket. BTW there are a lot of other typos in JDK, especially in comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From aturbanov at openjdk.java.net Thu Apr 14 18:09:37 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 14 Apr 2022 18:09:37 GMT Subject: Integrated: 8284853: Fix various 'expected' typo In-Reply-To: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, `expeced`, `Unexpeted`, etc. This pull request has now been integrated. Changeset: 48c75498 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/48c75498060f076287d3d44c49934db9ac70887b Stats: 65 lines in 28 files changed: 0 ins; 0 del; 65 mod 8284853: Fix various 'expected' typo Reviewed-by: bpb, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From ihse at openjdk.java.net Thu Apr 14 19:37:33 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Apr 2022 19:37:33 GMT Subject: Integrated: 8284891: Fix typos in build system files In-Reply-To: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com> References: <48sHX_PTeLN0flIYI_TiwTd3gsE3QGm3xw_iaoA6mTU=.2efe1eea-0398-43ca-ad71-3ce4671c0ffe@github.com> Message-ID: <2mF5V7umZUZe-exsy8TAj69oQs5CZ1A41lGknDaoNVc=.bf65fd9f-8851-4626-8bd1-6f23fef1e945@github.com> On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `make` directory, and accepted those changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > Most of the fixes are in comments. A few are in messages aimed at the user. This pull request has now been integrated. Changeset: 160eb2bd Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/160eb2bd392fea29dd690ee9781174d14dc0b659 Stats: 72 lines in 46 files changed: 0 ins; 0 del; 72 mod 8284891: Fix typos in build system files Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/8246 From psandoz at openjdk.java.net Thu Apr 14 21:42:08 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 21:42:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 862: > 860: * @param start the starting value of the counter > 861: * @return this builder > 862: * @throws IllegalArgumentException if count is negative Suggestion: * @throws IllegalArgumentException if start is negative ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Thu Apr 14 21:54:44 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 21:54:44 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 213: > 211: > 212: // Additional fields for platform threads > 213: private static class FieldHolder { All but the task field are explicitly known by the VM (and stillborn is not accessed by Java code. Suggest grouping accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Thu Apr 14 22:22:45 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 14 Apr 2022 22:22:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/Thread.java line 3028: > 3026: > 3027: /** The thread container that this thread is in */ > 3028: @Stable private volatile ThreadContainer container; The `volatile` modifier with `@Stable` is unusual. IIUC the field is set once on start (behaves as if a final field). Once C2 gets hold of it and can treat the value as a runtime constant the `volatile` has no effect. This is a tricky area but i think a store fence will suffice in `setThreadContainer` since the value goes from null to non-null and therefore cannot be speculated upon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Thu Apr 14 22:25:27 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 14 Apr 2022 22:25:27 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." Message-ID: During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: bool NativeInstruction::is_sigill_zombie_not_entrant() { return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead } void NativeIllegalInstruction::insert(address code_pos) { *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead } void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { ... if (Assembler::reachable_from_branch_at(verified_entry, dest)) { ... } else { // We use an illegal instruction for marking a method as // not_entrant or zombie. NativeIllegalInstruction::insert(verified_entry); } I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. ------------- Commit messages: - Fix issues with unexcpected exceptions during attach. Changes: https://git.openjdk.java.net/jdk/pull/8255/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8255&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283179 Stats: 40 lines in 1 file changed: 25 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8255/head:pull/8255 PR: https://git.openjdk.java.net/jdk/pull/8255 From psandoz at openjdk.java.net Fri Apr 15 00:19:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 00:19:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/VirtualThread.java line 65: > 63: * system. > 64: */ > 65: class VirtualThread extends Thread { Suggestion: final class VirtualThread extends Thread { src/java.base/share/classes/java/lang/VirtualThread.java line 94: > 92: * RUNNING -> PARKING // Thread attempts to park > 93: * PARKING -> PARKED // yield successful, thread is parked > 94: * PARKING -> PINNED // yield failed, thread is pinned Suggestion: * PARKING -> PARKED // parking successful, thread is parked * PARKING -> PINNED // parking failed, thread is pinned ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ihse at openjdk.java.net Fri Apr 15 07:47:15 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Apr 2022 07:47:15 GMT Subject: RFR: 8284903: Fix typos in hotspot Message-ID: I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... ------------- Commit messages: - Pass #2 - Pass #1 in shared code - Pass #1 in platform-specific code Changes: https://git.openjdk.java.net/jdk/pull/8260/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284903 Stats: 910 lines in 446 files changed: 0 ins; 0 del; 910 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From stuefe at openjdk.java.net Fri Apr 15 09:08:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 15 Apr 2022 09:08:44 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 17:08:32 GMT, Markus Gr?nlund wrote: > For additional context, I should add that the CrashProtection mechanism was mainly put in place as a result of having to deliver JFR from JRockit into Hotspot under a deadline, upholding feature-parity. The stack walking code was in really bad shape back then. Over the years, it has been hardened and improved much, and I have not seen any reported issues about JFR crashes in many years (we log when crashing in production). > > An important difference is that AGCT allows more thread states compared to JFR, so there can be issues in that area that are not seen in JFR. Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Fri Apr 15 10:07:41 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 15 Apr 2022 10:07:41 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 09:05:23 GMT, Thomas Stuefe wrote: > Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. I came to the same conclusion. Therefore I don't think that adding CrashProtection is worth the effort. > Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. ASGCT makes it possible to develop your own profiler. The implementation overlaps but the feature set does not. You cannot build your own profiler with JFR. AsyncProfiler has with ASGCT the possibility to capture call traces with different intervals that are related to perf-events which is not possible in JFR. ASGCT should be a best effort API that has its caveats, one of them being that it might crash the VM. I think the goal is to make ASGCT as safe as possible to use without altering the normal behaviour (and speed) of the VM. Calling the API should not alter anything on the heap or in any other data structures. This is also true for JFR and many stability fixes for ASGCT (like using SafeFetch in some places) should also benefit the stability of JFR. I therefore want to close this PR (and the related issue) and propose my "[Do not call JavaThread::thread_from_jni_environment](https://github.com/openjdk/jdk/pull/8225/commits/b16e85d2251ae8cf7433ff146ea209d094a37c8a)" commit in a new PR as adding PRs for all the errors I find in JFR and ASGCT seems to be the way forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From alanb at openjdk.java.net Fri Apr 15 11:45:01 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 11:45:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/0e12c206..f53f0d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=01-02 Stats: 148912 lines in 1502 files changed: 104901 ins; 9917 del; 34094 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From aturbanov at openjdk.java.net Fri Apr 15 12:34:47 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 15 Apr 2022 12:34:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java line 29: > 27: > 28: public interface JavaUtilConcurrentTLRAccess { > 29: int nextSecondaryThreadLocalRandomSeed(); method seems unused now ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Fri Apr 15 13:01:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 13:01:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <6wPsXjV1MP9Q86NWt2YOWecuHH0EXJwVjmPdA_baDFM=.56c7d00d-8169-4311-9d34-ac43e4ce64d0@github.com> On Thu, 14 Apr 2022 21:39:17 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/Thread.java line 862: > >> 860: * @param start the starting value of the counter >> 861: * @return this builder >> 862: * @throws IllegalArgumentException if count is negative > > Suggestion: > > * @throws IllegalArgumentException if start is negative Thanks, I think that dates from when the param was renamed. > src/java.base/share/classes/java/lang/VirtualThread.java line 65: > >> 63: * system. >> 64: */ >> 65: class VirtualThread extends Thread { > > Suggestion: > > final class VirtualThread extends Thread { okay. > src/java.base/share/classes/java/lang/VirtualThread.java line 94: > >> 92: * RUNNING -> PARKING // Thread attempts to park >> 93: * PARKING -> PARKED // yield successful, thread is parked >> 94: * PARKING -> PINNED // yield failed, thread is pinned > > Suggestion: > > * PARKING -> PARKED // parking successful, thread is parked > * PARKING -> PINNED // parking failed, thread is pinned The comment was about cont.yield, will change it to make it clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Fri Apr 15 13:01:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 15 Apr 2022 13:01:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 12:31:24 GMT, Andrey Turbanov wrote: > method seems unused now It's used by the SL API, which will follow later. I realize this may sound complicated but it avoids more complicated splits. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Fri Apr 15 13:47:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 15 Apr 2022 13:47:40 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov wrote: >> I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance and if a non-null instance is used to get a non-null class they are PROBABLY the same but it is far from clear. The implementations of both are at least native and may be instrinsicified. The doc for Class.isAssignableFrom cites JLS 5.1.4 which in what I found is about primitives so I suspect it is woefully out of date >> https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4 >> >> What client tests have you run that touch the code you are changing ? >> >> In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it. > >>In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it. > > I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_ operator. And `isInstance` method javadoc is very straight forward: `This method is the dynamic equivalent of the Java language instanceof operator.` > > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that: > 1. [Wrong isAssignableFrom test when adding Principal to Subject ](https://bugs.openjdk.java.net/browse/JDK-8034820) > 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8254717) > 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800) > > So, it gives all 3 points to prefer isInstance method: it's shorter, it's clearer for most java developers, it's faster. > @turbanoff > > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that: > > Maybe we should add `Class::isSubclassOf(Class that)` that performs `that.isAssignableFrom(this)`: I?have?opened [JI?9073064](https://bugs.openjdk.java.net/browse/JI-9073064 "[JI?9073064] Add?the?method `Class::isSublassOf(Class)` to?`java.lang.Class` that?does the?inverse of?`Class::isAssignableFrom`") for?this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From cjplummer at openjdk.java.net Fri Apr 15 19:30:34 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 15 Apr 2022 19:30:34 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... I tried to cover all serviceability files, but didn't want to pick and choose individual files within any given directory, so I reviewed all files in any directory that contained a serviceability related file. So the following were covered by my review: src/os src/os_cpu src/share/prims src/share/services src/hotspot/share/prims/jvmtiThreadState.hpp line 136: > 134: ~JvmtiThreadState(); > 135: > 136: // is event_type enabled and usable for this thread in any environments? Should it be "environment"? src/hotspot/share/services/memTracker.hpp line 128: > 126: > 127: // Record arena size change. Arena size is the size of all arena > 128: // chunks that backing up the arena. This doesn't read correctly (not due to your change). Perhaps "that back up" or "that are backing up" is what was intended. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From psandoz at openjdk.java.net Fri Apr 15 20:43:57 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 20:43:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/Blocker.java line 118: > 116: static long beginCompensatedBlock(ForkJoinPool pool) { > 117: try { > 118: return (long) beginCompensatedBlock.invoke(pool); Suggestion: return (long) beginCompensatedBlock.invokeExact(pool); src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126: > 124: static void endCompensatedBlock(ForkJoinPool pool, long post) { > 125: try { > 126: endCompensatedBlock.invoke(pool, post); Suggestion: endCompensatedBlock.invokeExact(pool, post); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 20:54:41 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 20:54:41 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46: > 44: } else { > 45: CAN_USE_INTERNAL_LOCK = true; > 46: } Suggestion: CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors"); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:04:54 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:04:54 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262: > 260: * @return the thread, started > 261: * @throws IllegalStateException if this flock is shutdown or closed > 262: * @throws jdk.incubator.concurrent.StructureViolationException if the current Suggestion: * @throws WrongThreadException if the current thread is not the owner or a thread * contained in the flock * @throws jdk.incubator.concurrent.StructureViolationException if the current ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:14:56 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:14:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59: > 57: && this.thread == other.thread; > 58: } > 59: } Suggestion: private record ThreadRef(Thread thread) { @Override public int hashCode() { return Long.hashCode(thread.threadId()); } @Override public boolean equals(Object obj) { return (obj instanceof ThreadRef other) && this.thread == other.thread; } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:18:52 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:18:52 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94: > 92: default: > 93: throw new AssertionError("Unknown pinned reason: " + reason); > 94: } Suggestion: return switch (reason) { case 2 -> Pinned.CRITICAL_SECTION; case 3 -> Pinned.NATIVE; case 4 -> Pinned.MONITOR; default -> throw new AssertionError("Unknown pinned reason: " + reason); }; ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:28:39 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:28:39 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > 113: } > 114: > 115: private Runnable target; Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:34:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:34:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264: > 262: } finally { > 263: fence(); > 264: StackChunk c = tail; `c` is not used src/java.base/share/classes/jdk/internal/vm/Continuation.java line 310: > 308: > 309: @IntrinsicCandidate > 310: private static int doYield() { throw new Error("Intrinsic not installed"); }; Suggestion: private static int doYield() { throw new Error("Intrinsic not installed"); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 21:39:41 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 21:39:41 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 474: > 472: private void processNmethods(int before, int after) { > 473: > 474: } Unused field and method? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 22:04:42 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 22:04:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: > 182: * with the Thread API. > 183: */ > 184: private static class RootContainer extends ThreadContainer { This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Fri Apr 15 22:13:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 15 Apr 2022 22:13:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35: > 33: * disables inlining for the method to which it is applied unless the > 34: * method being unlined into is also annotated ChangesCurrentThread. > 35: Suggestion: * method being inlined into is also annotated ChangesCurrentThread. * ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stuefe at openjdk.java.net Sat Apr 16 06:00:40 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 16 Apr 2022 06:00:40 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 10:04:12 GMT, Johannes Bechberger wrote: > > Thanks for the JFR insight, Marcus. I can see the CrashProtection being a stop-gap measure under time constraints. Maybe worth rethinking now. From your description, the way it is used in JFR differ significantly from how the async-profiler would use it. > > I came to the same conclusion. Therefore I don't think that adding CrashProtection is worth the effort. > > > Privately, I start wondering whether the benefits of async-profiler over JFR are worth the risk of corrupting the VM or the work needed to harden out AGCT. Their feature-set seems to overlap a lot. I may not see the whole picture though, I'm not a profiler expert. > > ASGCT makes it possible to develop your own profiler. The implementation overlaps but the feature set does not. You cannot build your own profiler with JFR. AsyncProfiler has with ASGCT the possibility to capture call traces with different intervals that are related to perf-events which is not possible in JFR. > > ASGCT should be a best effort API that has its caveats, one of them being that it might crash the VM. I disagree on this one, partly because you a crash is not the worst that could happen, that would be data corruption due to some freakish causal chain. And partly because that crashiness of AGCT is little known outside our community, so customers are probably not aware of this risk. > I think the goal is to make ASGCT as safe as possible to use without altering the normal behaviour (and speed) of the VM. Calling the API should not alter anything on the heap or in any other data structures. This is also true for JFR and many stability fixes for ASGCT (like using SafeFetch in some places) should also benefit the stability of JFR. > > I therefore want to close this PR (and the related issue) and propose my "[Do not call JavaThread::thread_from_jni_environment](https://github.com/openjdk/jdk/pull/8225/commits/b16e85d2251ae8cf7433ff146ea209d094a37c8a)" commit in a new PR as adding PRs for all the errors I find in JFR and ASGCT seems to be the way forward. Sounds reasonable. I'm sorry for frustrating your efforts here. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Sat Apr 16 07:10:35 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Sat, 16 Apr 2022 07:10:35 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 05:56:51 GMT, Thomas Stuefe wrote: > I disagree on this one, partly because you a crash is not the worst that could happen, that would be data corruption due to some freakish causal chain. Of course, but it is in reality far harder to test for. But ideally, ASGCT does never use a method that does alter state, at the expense that it might sometimes discard results. Even methods that modify caches (or comparable data structures) are problematic. I want to do a manual code analysis in the next few weeks of all code called by ASGCT (not just the parts that differ from JFR) to check whether this is true. > And partly because that crashiness of AGCT is little known outside our community, so customers are probably not aware of this risk. I don't think so, the problem are more transitive users that use a tool like AsyncProfiler that might crash their VM (or corrupt the data). > Sounds reasonable. I'm sorry for frustrating your efforts here. At least I learned something. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Sat Apr 16 07:10:35 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Sat, 16 Apr 2022 07:10:35 GMT Subject: Withdrawn: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger wrote: > Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). > This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). > > If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. > > _Thanks for @tstuefe for suggesting this._ This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From jpai at openjdk.java.net Sat Apr 16 09:28:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 09:28:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/BufferedOutputStream.java line 136: > 134: * are added. A no-op if the buffer is not resizable. > 135: */ > 136: private void growIfNeeded(int len) { Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sat Apr 16 10:32:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 10:32:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: > 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { > 75: ct.beginBlocking(); > 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94: > 92: > 93: /** > 94: * Marks the end an operation that may have blocked. I think this should have been "Marks the end of an ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sat Apr 16 11:09:36 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 16 Apr 2022 11:09:36 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/FilterInputStream.java line 233: > 231: */ > 232: @Override > 233: public void reset() throws IOException { I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 14:26:43 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:26:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> <52LXUMJwDqrd_x_5VFbI9ZhmRGfKyc8XT5HB4p5JoXk=.482b750b-00d2-4b6b-aefe-4468c2bb6107@github.com> Message-ID: On Fri, 15 Apr 2022 20:39:51 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126: > >> 124: static void endCompensatedBlock(ForkJoinPool pool, long post) { >> 125: try { >> 126: endCompensatedBlock.invoke(pool, post); > > Suggestion: > > endCompensatedBlock.invokeExact(pool, post); Yes, that would be better. > src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46: > >> 44: } else { >> 45: CAN_USE_INTERNAL_LOCK = true; >> 46: } > > Suggestion: > > CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors"); This doesn't work for the empty string case as it would map to true rather than false. So I think we leave this as is. > src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262: > >> 260: * @return the thread, started >> 261: * @throws IllegalStateException if this flock is shutdown or closed >> 262: * @throws jdk.incubator.concurrent.StructureViolationException if the current > > Suggestion: > > * @throws WrongThreadException if the current thread is not the owner or a thread > * contained in the flock > * @throws jdk.incubator.concurrent.StructureViolationException if the current Thanks, I think this slipped in when moving the SL API to the incubator module. It should be IllegalThreadStateException if the thread has already started, and WrongThreadException if not the owner (or flock). > src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59: > >> 57: && this.thread == other.thread; >> 58: } >> 59: } > > Suggestion: > > private record ThreadRef(Thread thread) { > @Override > public int hashCode() { > return Long.hashCode(thread.threadId()); > } > > @Override > public boolean equals(Object obj) { > return (obj instanceof ThreadRef other) > && this.thread == other.thread; > } > } Yes, this can be a record. > src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35: > >> 33: * disables inlining for the method to which it is applied unless the >> 34: * method being unlined into is also annotated ChangesCurrentThread. >> 35: > > Suggestion: > > * method being inlined into is also annotated ChangesCurrentThread. > * Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 14:33:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:33:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: <3DUMJmZ230xIecn-FP1iApMRFsr21tD2OGfZ-Sg2_Uc=.65d0cb79-e651-406c-aaa9-859937051963@github.com> On Sat, 16 Apr 2022 10:29:36 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 94: > >> 92: >> 93: /** >> 94: * Marks the end an operation that may have blocked. > > I think this should have been "Marks the end of an ..." Yes, there's a typo there - thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 14:37:44 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 14:37:44 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 10:25:56 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: > >> 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { >> 75: ct.beginBlocking(); >> 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); > > It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a corrects issue but we may be able to make this a bit more robust for these cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Sat Apr 16 14:45:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 16 Apr 2022 14:45:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111: > 109: methodType = MethodType.methodType(void.class, long.class); > 110: endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); > 111: This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`. Suggestion: JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); MethodType methodType = MethodType.methodType(long.class); beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType); if (beginCompensatedBlock == null) { throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType); } methodType = MethodType.methodType(void.class, long.class); endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); if (endCompensatedBlock == null) { throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 11:05:47 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/FilterInputStream.java line 233: > >> 231: */ >> 232: @Override >> 233: public void reset() throws IOException { > > I suspect this change to remove synchronization from `mark()` and `reset()` is intentional. The `FilterInputStream` class doesn't explain the thread safety semantics, nor can I find commit history which would hint on why these (and only these) methods were syncrhonized. But it looks like this synchronization was there to serialize calls to `mark()` and `reset()` on the same `FilterInputStream` from multiple threads. With this synchronization now removed, subclasses or even direct usages of `FilterInputStream` would now be impacted. Potentially outside of the JDK. Would that be a concern? Yes, this is intentional but it would be great to split out this change and get them into the main line in advance. There is a JEP size task required to re-visit all of the locking in java.io. In the case of the input/output streams, most of it is not documented and there are several inconsistencies. In the case of FilterInputStream, it doesn't use synchronization for the other ops. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: <6Y07wh7rpLs5SDolUCKoYqjmlst-6TKw03RpPubm0bM=.4401cd6d-e80a-48f9-bce2-77e9c757e4b2@github.com> On Sat, 16 Apr 2022 12:31:41 GMT, ExE Boss wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/misc/Blocker.java line 111: > >> 109: methodType = MethodType.methodType(void.class, long.class); >> 110: endCompensatedBlock = l.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); >> 111: > > This?can?use `SharedSecrets.getJavaLangInvokeAccess()` in?order to?avoid?using `privateLookupIn(?)` and?`AccessController.doPrivileged(?)`. > > Suggestion: > > JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); > MethodType methodType = MethodType.methodType(long.class); > beginCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "beginCompensatedBlock", methodType); > if (beginCompensatedBlock == null) { > throw new NoSuchMethodException(ForkJoinPool.class + ".beginCompensatedBlock" + methodType); > } > methodType = MethodType.methodType(void.class, long.class); > endCompensatedBlock = JLIA.findVirtual(ForkJoinPool.class, "endCompensatedBlock", methodType); > if (endCompensatedBlock == null) { > throw new NoSuchMethodException(ForkJoinPool.class + ".endCompensatedBlock" + methodType); > } I think we may just eliminate the reflection use and use a shared secret instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:02:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:02:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 22:01:10 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: > >> 182: * with the Thread API. >> 183: */ >> 184: private static class RootContainer extends ThreadContainer { > > This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat Apr 16 15:59:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 16 Apr 2022 15:59:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 09:25:20 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/BufferedOutputStream.java line 136: > >> 134: * are added. A no-op if the buffer is not resizable. >> 135: */ >> 136: private void growIfNeeded(int len) { > > Hello Alan, like some methods in other classes (BufferedInputStream#fill() for example), should we mention here that this method assumes that it's being called while a lock is held? Okay, we can add a comment to these methods (asserts are possible but tend not to be used in this area). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 03:34:35 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 03:34:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sat, 16 Apr 2022 14:34:01 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/Blocker.java line 76: >> >>> 74: && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { >>> 75: ct.beginBlocking(); >>> 76: long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); >> >> It appears that `ForkJoinPools.beginCompensatedBlock(...)` can throw an exception. Would such an exception require the CarrierThread's blocking state (which we set on the previous line) to be reset by a call to `ct.endBlocking()`? Or is it futile to reset that state if any exception gets thrown from the call to `ForkJoinPools.beginCompensatedBlock(...)`? > > REE isn't possible here but maybe you mean a resource issues such as stack overflow or OOME. If that happens then the flag wouldn't be reset. It wouldn't a correctness issue but we may be able to make this a bit more robust for these cases. Hello Alan, My concern wasn't really about OOME or resource issue. I had noticed the `ForkJoinPools.beginCompensatedBlock` has a try/catch which then propagates back the `Throwable`. So I thought there could be some genuine exceptions that could be thrown in this flow which ultimately calls `ForkJoinPool.beginCompensatedBlock()`. I haven't yet reached the changes in `ForkJoinPool.java` class itself, so it's likely that this catch block is only there for theoretical reasons when dealing with `MethodHandle`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 03:52:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 03:52:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/io/PrintStream.java line 1420: > 1418: } else { > 1419: synchronized (this) { > 1420: implFormat(format, args); I think there's a typo here. I think it should have been: implFormat(l, format, args); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 05:00:40 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 05:00:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/StackTraceElement.java line 556: > 554: } > 555: > 556: static StackTraceElement[] of(StackTraceElement[] stackTrace) { Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 06:19:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 06:19:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 602: > 600: } else { > 601: // getContextClassLoader not trusted > 602: ClassLoader cl = parent.contextClassLoader; I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are. It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be: if (sm == null || !isCCLOverridden(parent.getClass())) { return parent.getContextClassLoader(); } (notice the negation) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 06:58:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 06:58:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 03:49:19 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/io/PrintStream.java line 1420: > >> 1418: } else { >> 1419: synchronized (this) { >> 1420: implFormat(format, args); > > I think there's a typo here. I think it should have been: > > > implFormat(l, format, args); Well spotted, the locale should be provided. > src/java.base/share/classes/java/lang/Thread.java line 602: > >> 600: } else { >> 601: // getContextClassLoader not trusted >> 602: ClassLoader cl = parent.contextClassLoader; > > I might be misreading the comment on that line, but reading this if/else block a few times, I'm unsure what the expectations here are. > > It's my understanding that a call to `getContextClassLoader()` can't be trusted if that method has been overridden by the passed `Thread` type. In such cases, we don't call that method and instead just use the field value of `contextClassLoader` (which is a private field on `Thread`). Is that understanding correct? If yes, then the condition in the `if` block a few lines above, looks odd. It seems to be calling the `getContextClassLoader()` if that method is overridden by the passed `Thread` type, i.e. the untrusted case. Should it instead be: > > if (sm == null || !isCCLOverridden(parent.getClass())) { > return parent.getContextClassLoader(); > } > > (notice the negation) This code hasn't changed, it's just moved to a helper method. When running with a security manager and the CCL methods aren't overridden, then it avoids the permission check. However, I can see how the comment is mis-reading so we can improve that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 12:42:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 12:42:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 1554: > 1552: * Null out reference after Thread termination (JDK-4006245) > 1553: */ > 1554: void clearReferences() { I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations. With the new implementation in this PR, this `clearReferences()` will no longer set the user/application `task` instance to `null`. I understand why we aren't doing that - the `task` field in the `FieldHolder` is `final` (IMO, rightly so). This, in theory, undoes what JDK-4006245 had implemented. I don't know if we still need such a change here and I'm just bringing this up to see if anyone else has any opinions or if any additional experiments need to be run in context of this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jpai at openjdk.java.net Sun Apr 17 13:36:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 17 Apr 2022 13:36:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push src/java.base/share/classes/java/lang/Thread.java line 2414: > 2412: sm.checkPermission(new RuntimePermission("setContextClassLoader")); > 2413: } > 2414: if (!isSupportedClassLoader(contextClassLoader)) { For a few moments, I thought this was a typo and should instead have been: if (!isSupportedClassLoader(cl)) { but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`). Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:30 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: Message-ID: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/f53f0d4e..ff1ef712 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=02-03 Stats: 1517 lines in 74 files changed: 1034 ins; 311 del; 172 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:31 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:31 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 12:39:24 GMT, Jaikiran Pai wrote: > I had a look at the referenced [JDK-4006245](https://bugs.openjdk.java.net/browse/JDK-4006245). The previous/existing reference cleaning logic seems to have been added mainly to `null` the reference to the user/application class instance represented by the `Runnable` task. Of course, other references too were being cleared. The description in the linked JBS seems to suggest that the `Thread` instance wasn't being GCed sooner. That was more than 2 decades back. I don't have enough knowledge of this area to know if this is still an issue in recent GC implementations. The comment on that method dates from early JDK releases with the Classic VM and its conservative GC. It also predates the java.lang.ref API. The question that I think you are asking is if you create a Thread with a runnable task, let it terminate but keep the reference to the Thread forever then what does it keep alive. We can think about more but so far we haven't seen any issues or tests fail with the reference to the runnable task. > src/java.base/share/classes/java/lang/Thread.java line 2414: > >> 2412: sm.checkPermission(new RuntimePermission("setContextClassLoader")); >> 2413: } >> 2414: if (!isSupportedClassLoader(contextClassLoader)) { > > For a few moments, I thought this was a typo and should instead have been: > > if (!isSupportedClassLoader(cl)) { > > but then thinking a bit more, I realized what's being done here. Essentially, this checks whether the _current_ context classloader is set to "not allowed to change/set context classloader" (represented by `Constants.NOT_SUPPORTED_CLASSLOADER`). > > Do you think this line deserves some short code comment that it intentionally passes the current contextClassLoader (and not the one passed to the method) to `isSupportedClassLoader`? I think the comment on isSupportedClassLoader is readable so I think it's okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sun Apr 17 16:03:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 17 Apr 2022 16:03:32 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:15:45 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94: > >> 92: default: >> 93: throw new AssertionError("Unknown pinned reason: " + reason); >> 94: } > > Suggestion: > > return switch (reason) { > case 2 -> Pinned.CRITICAL_SECTION; > case 3 -> Pinned.NATIVE; > case 4 -> Pinned.MONITOR; > default -> throw new AssertionError("Unknown pinned reason: " + reason); > }; That would be clearer (I think this predates switch expressions). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Mon Apr 18 12:22:56 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 18 Apr 2022 12:22:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 266: > 264: * contained in the flock > 265: * @throws jdk.incubator.concurrent.StructureViolationException if the current > 266: * scope-local bindings are not the same as when the flock was created Suggestion: * scope-local bindings are not the same as when the flock was created ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Mon Apr 18 18:00:40 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 18 Apr 2022 18:00:40 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... I checked all directories except gc, jfr, metaspace, opto and jvmti. It's surprising that there aren't more typos. The changes to each file are tiny (one word to three words). ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From kvn at openjdk.java.net Mon Apr 18 18:40:40 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 18 Apr 2022 18:40:40 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: <0CKX2hdjVTCzFrtYznCHOfTWFFkRvKBfQilIOETpBK4=.b72aaefe-d6c6-4a2e-ba29-cc6198576d91@github.com> On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Nice work! I reviewed compiler related code: `cpu`, `os`, `os_cpu`, `share/adlc`, `share/c1`, `share/ci`, `share/code`, `share/compiler`, `share/jvmci`, `share/opto`. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From mchung at openjdk.java.net Mon Apr 18 22:49:43 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 18 Apr 2022 22:49:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655: > 653: * synchronization control. It might be an expensive operation. > 654: * Its behavior with cycles involving virtual threads is not defined > 655: * in this release. What does the current implementation return if the virtual threads are involved in a deadlock? The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined. I wonder if it's helpful to include `@implNote` if appropriate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Tue Apr 19 00:09:37 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 00:09:37 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206: > 204: throws IllegalArgumentException, InterruptedException { > 205: if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); > 206: if (timeout == 0) return remove(); Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file. if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); if (timeout == 0) return remove(); ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 19 00:26:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 00:26:42 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Hi Magnus, Generally looks good. Thanks for doing this extremely tedious cleanup. A few comments/suggestions/corrections below. And of course copyright dates need updating for Oracle copyrights. Thanks, David src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp line 125: > 123: bool LIRGenerator::can_store_as_constant(Value v, BasicType type) const { > 124: if (type == T_SHORT || type == T_CHAR) { > 125: // there is no immediate move of word values in assembler_i486.?pp Dead comment as there is no such file any more. src/hotspot/cpu/x86/macroAssembler_x86.hpp line 865: > 863: > 864: // 32bit can do a case table jump in one instruction but we no longer allow the base > 865: // to be installed in the Address class. This jump will transfers to the address transfer not transfers src/hotspot/share/c1/c1_Runtime1.cpp line 552: > 550: Exceptions::debug_check_abort(exception); > 551: > 552: // Check the stack guard pages and re-enable them if necessary and there is Curious how inconsistent hyphenation rules are in English :) I would use reenable in the same way we use mismatch. src/hotspot/share/code/nmethod.cpp line 2906: > 2904: > 2905: // Compressed undisassembled disassembly format. > 2906: // The following statuses are defined/supported: status is the more usual self-plural - or use "status values" src/hotspot/share/runtime/os.cpp line 644: > 642: DEBUG_ONLY(check_crash_protection()); > 643: > 644: // On malloc(0), implementers of malloc(3) have the choice to return either I suggest "implementations of malloc..." src/hotspot/share/runtime/task.hpp line 72: > 70: void enroll(); > 71: > 72: // Make the task deactivate Should be "inactive" src/hotspot/share/services/threadIdTable.cpp line 94: > 92: if (!_is_initialized) { > 93: { > 94: // There is no obvious benefits in allowing the thread table s/benefits/benefit/ src/hotspot/share/services/threadIdTable.cpp line 95: > 93: { > 94: // There is no obvious benefits in allowing the thread table > 95: // to be concurrently populated during the initialization. delete "the" ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From mchung at openjdk.java.net Tue Apr 19 02:03:35 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 02:03:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/System.java line 2173: > 2171: > 2172: // start Finalizer and Reference Handler threads > 2173: SharedSecrets.getJavaLangRefAccess().startThreads(); I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line. Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available. With this change, `JavaLangAccess` is already set. src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: > 59: private final Condition notEmpty; > 60: > 61: void signal() { notEmpty.signalAll(); } `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138: > 136: * > 137: * @param outputFile the path to the file to create > 138: * @param format the format to use (TEXT_PLAIN or JSON) It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON` ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue Apr 19 02:59:25 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 02:59:25 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 22:16:36 GMT, Chris Plummer wrote: > During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. > > The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: > > > bool NativeInstruction::is_sigill_zombie_not_entrant() { > return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeIllegalInstruction::insert(address code_pos) { > *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { > ... > if (Assembler::reachable_from_branch_at(verified_entry, dest)) { > ... > } else { > // We use an illegal instruction for marking a method as > // not_entrant or zombie. > NativeIllegalInstruction::insert(verified_entry); > } > > > I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. > > Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). > > The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. Hi Chris, Based on your description this approach seems quite reasonable. I take it that we can't install an exception handler only for the SIGSTOP (like how we would install a signal handler only for SIGSTOP) ? Thanks, David src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 864: > 862: exception_port, thread_port, task_port, exception_type, num_codes); > 863: > 864: // Uncommon traps in the JVM can result in a "crash. We just ignore them. Missing " after crash ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8255 From cjplummer at openjdk.java.net Tue Apr 19 04:01:16 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Apr 2022 04:01:16 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: > During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. > > The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: > > > bool NativeInstruction::is_sigill_zombie_not_entrant() { > return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeIllegalInstruction::insert(address code_pos) { > *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { > ... > if (Assembler::reachable_from_branch_at(verified_entry, dest)) { > ... > } else { > // We use an illegal instruction for marking a method as > // not_entrant or zombie. > NativeIllegalInstruction::insert(verified_entry); > } > > > I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. > > Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). > > The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Minor comment fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8255/files - new: https://git.openjdk.java.net/jdk/pull/8255/files/f170e847..4d36edce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8255&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8255&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8255.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8255/head:pull/8255 PR: https://git.openjdk.java.net/jdk/pull/8255 From cjplummer at openjdk.java.net Tue Apr 19 04:01:16 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Apr 2022 04:01:16 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 02:56:28 GMT, David Holmes wrote: > Based on your description this approach seems quite reasonable. I take it that we can't install an exception handler only for the SIGSTOP (like how we would install a signal handler only for SIGSTOP) ? On the debugger side I don't think you can other than with an exception handler like the one already being used. On the JVM side it just uses posix signals like any other unix port. ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From dholmes at openjdk.java.net Tue Apr 19 04:25:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Apr 2022 04:25:24 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote: >> During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. >> >> The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: >> >> >> bool NativeInstruction::is_sigill_zombie_not_entrant() { >> return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeIllegalInstruction::insert(address code_pos) { >> *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { >> ... >> if (Assembler::reachable_from_branch_at(verified_entry, dest)) { >> ... >> } else { >> // We use an illegal instruction for marking a method as >> // not_entrant or zombie. >> NativeIllegalInstruction::insert(verified_entry); >> } >> >> >> I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. >> >> Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). >> >> The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment fix. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From dnsimon at openjdk.java.net Tue Apr 19 08:52:28 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 19 Apr 2022 08:52:28 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Are there plans to add `codespell` to the make system to somehow catch/prevent spelling regressions in future? I understand this may not be feasible. ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From duke at openjdk.java.net Tue Apr 19 09:01:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 19 Apr 2022 09:01:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 08:49:28 GMT, Doug Simon wrote: > Are there plans to add `codespell` to the make system to somehow catch/prevent spelling regressions in future? I understand this may not be feasible. IMO all spell checking mechanisms suffers from false positive and need human manual job to filter them... So maybe we can only arrange a scan per year or per months... ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From alanb at openjdk.java.net Tue Apr 19 10:52:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 19 Apr 2022 10:52:30 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Tue, 19 Apr 2022 00:09:04 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: > >> 59: private final Condition notEmpty; >> 60: >> 61: void signal() { notEmpty.signalAll(); } > > `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. They are overridden so can't be private. > src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 206: > >> 204: throws IllegalArgumentException, InterruptedException { >> 205: if (timeout < 0) throw new IllegalArgumentException("Negative timeout value"); >> 206: if (timeout == 0) return remove(); > > Nit: use the same formatting as in `NativeReferenceQueue::remove` and in this file. > > > if (timeout < 0) > throw new IllegalArgumentException("Negative timeout value"); > if (timeout == 0) > return remove(); okay > src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 655: > >> 653: * synchronization control. It might be an expensive operation. >> 654: * Its behavior with cycles involving virtual threads is not defined >> 655: * in this release. > > What does the current implementation return if the virtual threads are involved in a deadlock? The class spec says "ThreadMXBean does not support monitoring or management of virtual threads" while this javadoc says it's undefined. I wonder if it's helpful to include `@implNote` if appropriate. If there is cycle involving a virtual thread then the thread id of its carrier will be included in array. I think we can do better and include the thread id of the mounted thread. > src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 138: > >> 136: * >> 137: * @param outputFile the path to the file to create >> 138: * @param format the format to use (TEXT_PLAIN or JSON) > > It's useful to link to `ThreadDumpFormat#TEXT_PLAN` and `ThreadDumpFormat#JSON` I think it might be better if the description is changed to "the format to use". There is already a link to the ThreadDumpFormat enum in method signature. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ihse at openjdk.java.net Tue Apr 19 14:04:25 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 14:04:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Thank you for all your input! I will update the PR according to all suggestions. But let me answer a few more general comments first. The spelling corrections in this PR was generated by codespell. I manually removed all false positives (that was the most tedious part of this fix). Codespell works by checking a list of commonly misspelled words, not by verifying that all words are present in a list of accepted spellings. The latter approach might work for normal prose, but is utterly worthless for source code. In practice, codespell does automatically what several users have been doing manually lately -- discover a common misspelling, searching the code base for more instances of that misspelling. So, there are certainly lots of typos left. But this should reasonably cut down on the number of PRs of the type "Fix typos for supercalifragilisticexpialidocious" that updates a lot of files for just a single misspelled word. For some cases where I were not sure (like mismatch or re-enable), I googled, read spelling recommendations and/or checked how common alternative spellings where. When the ratio exceeded 10:1 or so, I deemed one alternative as "correct"; in less common cases I let the original authors choice of spelling remain. I have not read the complete sentences, just verified that the actual word fixes seemed to make sense. Hence the odd results in some places. Ideally, I would like to find some way of keeping the code "codespell clean" using tooling. Due to the amount of false positives, this is not a trivial task. I don't think we'll ever be able to have it as part of jcheck, but we might have a script that someone runs once per release or so. I'm not yet sure how to achieve this, but my two main ideas is to either just run codespell on added or modified code (think "+" lines in git diff), or to have a list of acknowledged false positives that should be skipped. Before I can even start on this, the huge number of *true* positives needs to be addressed, though! Hotspot is by no means worst, it's just a huge chunk of code which I addressed all at once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From lkorinth at openjdk.java.net Tue Apr 19 16:49:12 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Apr 2022 16:49:12 GMT Subject: RFR: 8269537: memset() is called after operator new [v5] In-Reply-To: References: Message-ID: > The basic problem is that we are relying on undefined behaviour, as documented in the code: > > // This whole business of passing information from ResourceObj::operator new > // to the ResourceObj constructor via fields in the "object" is technically UB. > // But it seems to work within the limitations of HotSpot usage (such as no > // multiple inheritance) with the compilers and compiler options we're using. > // And it gives some possibly useful checking for misuse of ResourceObj. > > > I am removing the undefined behaviour by passing the type of allocation through a thread local variable. > > This solution has some advantages: > 1) it is not UB > 2) it is simpler and easier to understand > 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) > 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. > > When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. > > I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. > > This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. > > I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. > > Testing on debug build tier1-3 > Testing on release build tier1 Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into _8269537 - Merge branch 'master' into _8269537 - review updates - Use a thread local buffer so that the compiler might reorder operator new. - First update * Change backing type of ResourceObj::allocation_type to be u8. Also remove no longer needed mask and explicit zero value of STACK_OR_EMBEDDED value. * Now setting allocation type with set_type() with assert. - 8269537: memset() is called after operator new ------------- Changes: https://git.openjdk.java.net/jdk/pull/5387/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5387&range=04 Stats: 174 lines in 8 files changed: 48 ins; 93 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5387/head:pull/5387 PR: https://git.openjdk.java.net/jdk/pull/5387 From mchung at openjdk.java.net Tue Apr 19 16:52:34 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 19 Apr 2022 16:52:34 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: On Tue, 19 Apr 2022 10:49:14 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61: >> >>> 59: private final Condition notEmpty; >>> 60: >>> 61: void signal() { notEmpty.signalAll(); } >> >> `signal()`, `await()` and `await(long)` methods are only used by `ReferenceQueue`. Good to make them private. > > They are overridden so can't be private. That's right, I missed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lkorinth at openjdk.java.net Tue Apr 19 16:53:38 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Tue, 19 Apr 2022 16:53:38 GMT Subject: RFR: 8269537: memset() is called after operator new [v5] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 16:49:12 GMT, Leo Korinth wrote: >> The basic problem is that we are relying on undefined behaviour, as documented in the code: >> >> // This whole business of passing information from ResourceObj::operator new >> // to the ResourceObj constructor via fields in the "object" is technically UB. >> // But it seems to work within the limitations of HotSpot usage (such as no >> // multiple inheritance) with the compilers and compiler options we're using. >> // And it gives some possibly useful checking for misuse of ResourceObj. >> >> >> I am removing the undefined behaviour by passing the type of allocation through a thread local variable. >> >> This solution has some advantages: >> 1) it is not UB >> 2) it is simpler and easier to understand >> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8) >> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. >> >> When doing the change, I also updated `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret. >> >> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`. >> >> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. >> >> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new. >> >> Testing on debug build tier1-3 >> Testing on release build tier1 > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into _8269537 > - Merge branch 'master' into _8269537 > - review updates > - Use a thread local buffer so that the compiler might reorder operator new. > - First update > > * Change backing type of ResourceObj::allocation_type to be u8. Also remove no longer needed mask and explicit zero value of STACK_OR_EMBEDDED value. > > * Now setting allocation type with set_type() with assert. > - 8269537: memset() is called after operator new Rebased. I think my approach is better than the current. I think we would be better off without tracking the allocation type at all though, so please consider that approach as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5387 From lucy at openjdk.java.net Tue Apr 19 17:32:25 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 19 Apr 2022 17:32:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... This is a partial approval for - cpu/ppc - cpu/s390 - os/aix - os_cpu/aix_ppc - os_cpu/linux_ppc - os_cpu/linux_s390 Thank you for completing this tedious job! ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From stefank at openjdk.java.net Tue Apr 19 18:06:25 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 19 Apr 2022 18:06:25 GMT Subject: RFR: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Reviewed: - gc/ - oops/ - utilities/ ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:08:26 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:08:26 GMT Subject: RFR: 8284903: Fix typos in hotspot [v2] In-Reply-To: References: Message-ID: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix some places according to code reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8260/files - new: https://git.openjdk.java.net/jdk/pull/8260/files/449d8a23..28bb365f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=00-01 Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:13:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:13:03 GMT Subject: RFR: 8284903: Fix typos in hotspot [v3] In-Reply-To: References: Message-ID: <3Is0RhXgzstSAZW41f6AGki3RZtWmBm8x4yuRZSz4OE=.da5d7f88-92e4-4a3f-9e5c-407d768d3618@github.com> > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8260/files - new: https://git.openjdk.java.net/jdk/pull/8260/files/28bb365f..4fc36d6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8260&range=01-02 Stats: 287 lines in 287 files changed: 0 ins; 0 del; 287 mod Patch: https://git.openjdk.java.net/jdk/pull/8260.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8260/head:pull/8260 PR: https://git.openjdk.java.net/jdk/pull/8260 From ihse at openjdk.java.net Tue Apr 19 19:14:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Apr 2022 19:14:02 GMT Subject: Integrated: 8284903: Fix typos in hotspot In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. > > You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... This pull request has now been integrated. Changeset: 4594696f Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/4594696f5462995ec58ca1d2c1bde7cc857c5caf Stats: 1197 lines in 446 files changed: 0 ins; 1 del; 1196 mod 8284903: Fix typos in hotspot Reviewed-by: cjplummer, coleenp, kvn, lucy, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From cjplummer at openjdk.java.net Tue Apr 19 19:36:21 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 19 Apr 2022 19:36:21 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: <4y9ucO3tP6IePWD8UzXOW7IdE40ijxBFVA8Q05pD4Js=.2c856e1c-4807-4bfb-a86b-f97afc9d20f5@github.com> On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote: >> During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. >> >> The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: >> >> >> bool NativeInstruction::is_sigill_zombie_not_entrant() { >> return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeIllegalInstruction::insert(address code_pos) { >> *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { >> ... >> if (Assembler::reachable_from_branch_at(verified_entry, dest)) { >> ... >> } else { >> // We use an illegal instruction for marking a method as >> // not_entrant or zombie. >> NativeIllegalInstruction::insert(verified_entry); >> } >> >> >> I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. >> >> Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). >> >> The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment fix. Thanks for the review, David. Can I get one more reviewer please? ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From dholmes at openjdk.java.net Wed Apr 20 06:17:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Apr 2022 06:17:43 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null Just for the record I was happy to return from vacation and see this had resolved into something not going forward. AGCT is a legacy mechanism that was created for one single unsupported purpose. It is inherently unsafe to hit a thread with a signal and then try to figure out what kind of introspection the thread can do upon itself. If you want to try and produce a more robust, "supported" version of AGCT then there needs to be a commitment of resources and support going forward - as would be established by the JEP process. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From dholmes at openjdk.java.net Wed Apr 20 06:23:27 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 20 Apr 2022 06:23:27 GMT Subject: RFR: 8284903: Fix typos in hotspot [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 19:08:26 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on hotspot, and accepted those changes where it indeed discovered real typos. >> >> You'd be surprised over the many implementions of instrinsics and other intructions accross all archtectures I've encounted, so for the preceding reason it's neccesery to sucessfully seach for exisiting typos... > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix some places according to code reviews src/hotspot/share/runtime/task.hpp line 72: > 70: void enroll(); > 71: > 72: // Make the task inactivate That should have been "inactive". ------------- PR: https://git.openjdk.java.net/jdk/pull/8260 From kevinw at openjdk.java.net Wed Apr 20 14:04:32 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 20 Apr 2022 14:04:32 GMT Subject: RFR: 8284853: Fix various 'expected' typo [v2] In-Reply-To: References: <32dmK9fPqvYhxpZmTgVYMYCfJNLZ3bI8ROg9UqUIRHc=.25e61d1a-6f26-4ea4-b5d3-3c6a80ce08dd@github.com> Message-ID: On Thu, 14 Apr 2022 18:04:16 GMT, Andrey Turbanov wrote: > I found [yet another typo](https://github.com/kelthuzadx/jdk/commit/acb9e15bc0bf5395d1c0875f36992f692734f948) ... I didn't think "JVMInvokeMethodSlack" was a typo. I think it's the idea of "slack space" meaning leftover space. We require a certain amount of this space. We need some slack on the stack, in order to invoke. ------------- PR: https://git.openjdk.java.net/jdk/pull/8231 From duke at openjdk.java.net Wed Apr 20 16:03:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 16:03:49 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) Message-ID: These are the changes that too many to be reviewed in 8186958, thus split some of them out. ------------- Commit messages: - 9073085: ues HashMap.newHashMap to replace new HashMap(int) Changes: https://git.openjdk.java.net/jdk/pull/8301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285149 Stats: 36 lines in 20 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 20 16:27:36 2022 From: duke at openjdk.java.net (liach) Date: Wed, 20 Apr 2022 16:27:36 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess wrote: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. Would you consider replacing usages of `new HashMap<>(size, 1)`, such as in `AnnotationInvocationHandler`, as well? Such maps have a smaller table and are more likely to have collisions than `HashMap.newHashMap(size)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 20 18:32:22 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 18:32:22 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v2] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - add more replaces - add more replaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/2ac4d7bc..28afb90b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=00-01 Stats: 109 lines in 64 files changed: 0 ins; 10 del; 99 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 20 18:42:39 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 20 Apr 2022 18:42:39 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null This is what the ASGCT2 JEP is for. I'm happy to discuss my JEP draft with you next week, drop me a mail when you have time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From duke at openjdk.java.net Wed Apr 20 19:24:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 20 Apr 2022 19:24:25 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: add more replaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/28afb90b..4f2d4838 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From kustos at gmx.net Wed Apr 20 20:13:20 2022 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 20 Apr 2022 22:13:20 +0200 Subject: Interest in Java based attach provider implementation? Message-ID: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net> Hello I hope this is the right mailing list. I recently had a look at the Linux attach provider implementation and could not help but noticing that a large part, if not all of it, could be replaced with Java. Besides getting rid of the C code this should allow us to unify the AIX, Linux and macOS implementations under a single Unix implementation. The permission check can be implemented using JSR 203 [1] to access uid, gid and file mode and using jdk.internal.misc.VM to get the euid and egid. Reading and writing to Unix domain sockets can be done through JEP 380 [2]. Sending SIGQUIT to a process could in theory done through JEP 102 [3] however sending SIGQUIT to self is currently blocked. This is required for the self attach mechanism. There a very small C function is still needed for now, this is hopefully portable. I did a small prototype [4]. The tier1 suite runs and I can attach to a local JVM. The overhead will likely be a bit higher as we go through more JDK abstractions. [1] https://jcp.org/en/jsr/detail?id=203 [2] https://openjdk.java.net/jeps/380 [3] https://openjdk.java.net/jeps/102 [4] https://github.com/marschall/jdk/commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc Cheers Philippe From dholmes at openjdk.java.net Thu Apr 21 03:11:26 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 21 Apr 2022 03:11:26 GMT Subject: RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v9] In-Reply-To: References: Message-ID: <_3ndQ6uF29rGkGMmcxHykEIE1gAMyIxa8oXmxkz3Kxw=.188d2075-f2ed-4210-b4d4-80c8a1f1a5fa@github.com> On Thu, 14 Apr 2022 15:19:17 GMT, Johannes Bechberger wrote: >> Move the AsyncGetCallTrace method implementation into a separate method and wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` like it is done in [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to `ticks_unknown_state` (-7) to signal a state that cannot be properly handled. `ticks_unknown_state` is currently also used for signaling unknown thread states but this should not be a problem, as the semantic is the same. If `num_frames` already has an error code then this error code is not changed. This helps to distinguish between errors in walking threads in Java and non-Java mode, as `num_frames` is set there before the walking to the appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use JavaThread::current_or_null Sorry I wasn't clear - doing this kind of change as part of the ASGCT2 JEP is what I was suggesting. But that is not a JEP that I can actively get involved in. It is really for the serviceability team and JFR team to comment on. Unfortunately folks are very busy at the moment due to the Project Loom preview, so it may be hard to get that discussion going. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225 From ayang at openjdk.java.net Thu Apr 21 10:56:08 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 10:56:08 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER Message-ID: Simple rename and some comments update. Test: build ------------- Commit messages: - ref-rename Changes: https://git.openjdk.java.net/jdk/pull/8332/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285364 Stats: 9 lines in 7 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From kbarrett at openjdk.java.net Thu Apr 21 11:18:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Apr 2022 11:18:55 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 10:48:06 GMT, Albert Mingkun Yang wrote: > Simple rename and some comments update. > > Test: build Changes requested by kbarrett (Reviewer). src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp line 214: > 212: } > 213: > 214: static const char* reference_type_to_string(ReferenceType rt) { This function seems misplaced here. Seems like it belongs with the ReferenceType type. (This could be a followup RFE.) src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp line 217: > 215: switch (rt) { > 216: case REF_NONE: return "None reference"; > 217: case REF_REFERENCE: return "j.l.r.Reference"; I think either "Reference" or "java.lang.ref.Reference" would be better than the abbreviation. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/ReferenceType.java line 31: > 29: public enum ReferenceType { > 30: REF_NONE ("None reference"), // Regular class > 31: REF_REFERENCE ("j.l.r.Reference"), // java/lang/ref/Reference, super class of the following Again here, don't abbreviate the package path. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 21 11:30:20 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 11:30:20 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/6423f0ad..746ff8e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ihse at openjdk.java.net Thu Apr 21 11:30:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 11:30:48 GMT Subject: RFR: 8285366: Fix typos in serviceability Message-ID: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. ------------- Commit messages: - Pass #2 - Pass #1 Changes: https://git.openjdk.java.net/jdk/pull/8334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285366 Stats: 203 lines in 137 files changed: 0 ins; 0 del; 203 mod Patch: https://git.openjdk.java.net/jdk/pull/8334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8334/head:pull/8334 PR: https://git.openjdk.java.net/jdk/pull/8334 From alanb at openjdk.java.net Thu Apr 21 11:35:57 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:35:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: Message-ID: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/ff1ef712..5e202eca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=03-04 Stats: 1827 lines in 289 files changed: 682 ins; 377 del; 768 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:35:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:35:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v4] In-Reply-To: References: <_TWRNeLakN4zFnF3jIC_2ezkgvSzl-9O5xtV7qI-NDA=.b07a1c1a-edc1-4078-b580-a065a28a7b1f@github.com> Message-ID: <-G75Xv0RAXFvZt1TM0JXiQk9R5YX_SPAUennszGlXMA=.fde68d79-9d39-417c-8bec-e21ec04df70d@github.com> On Tue, 19 Apr 2022 01:11:56 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/System.java line 2173: > >> 2171: >> 2172: // start Finalizer and Reference Handler threads >> 2173: SharedSecrets.getJavaLangRefAccess().startThreads(); > > I think it would avoid any confusion if `VM.initLevel(1)` is the last step in `initPhase1`, i.e. call after this line. Previously, the finalizer starts very early and it has to wait until initLevel is set to level 1 which guarantees that `JavaLangAccess` is available. With this change, `JavaLangAccess` is already set. Yes, that would be best, just wasn't possible before now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:36:02 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:36:02 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:31:09 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264: > >> 262: } finally { >> 263: fence(); >> 264: StackChunk c = tail; > > `c` is not used Ron has done some cleanup so this is removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 21 11:36:04 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 21 Apr 2022 11:36:04 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Sat, 16 Apr 2022 14:59:55 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184: >> >>> 182: * with the Thread API. >>> 183: */ >>> 184: private static class RootContainer extends ThreadContainer { >> >> This implementation could be clearer if split out into two, and the value assigned to `INSTANCE` is selected based on the system property. Something to consider later perhaps. > > We've been undecided on whether to just track all threads. If we do that then there would be only one implementation. But yes, if we continue with two then they should be split out. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stefank at openjdk.java.net Thu Apr 21 11:38:39 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Apr 2022 11:38:39 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Do we even need REF_OTHER / REF_REFERENCE? I see a bunch of ShouldNotReachHeres and then set_reference_type(REF_OTHER). Maybe the latter could be changed to REF_NONE? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 21 11:47:28 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 11:47:28 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:36:35 GMT, Stefan Karlsson wrote: > Maybe the latter could be changed to REF_NONE? `vmClasses::Reference_klass()->set_reference_type(REF_NONE);` fails in `make images`. The relevant code is: ClassFileParser::post_process_parsed_stream(...) { ... _rt = (NULL ==_super_klass) ? REF_NONE : _super_klass->reference_type(); } InstanceKlass::allocate_instance_klass(...) { ... if (REF_NONE == parser.reference_type()) { ... } else { // reference ik = new (loader_data, size, THREAD) InstanceRefKlass(parser); } } The `else` branch is for non-strong refs and relies on the ref-type of their super klass not being `REF_NONE`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From stefank at openjdk.java.net Thu Apr 21 12:22:25 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Apr 2022 12:22:25 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review That's unfortunate. The allocate_instance_klass function can easily be changed to also check if class_name == vmSymbols::java_lang_ref_Reference(). But even with that, make images fails. I wasn't a fan of the REF_REFERENCE name, since it isn't really that descriptive to me, and had hoped to fine a way to just get rid of it instead of finding a better name. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From dfuchs at openjdk.java.net Thu Apr 21 14:06:36 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 21 Apr 2022 14:06:36 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. > > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From ayang at openjdk.java.net Thu Apr 21 15:12:26 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Apr 2022 15:12:26 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: <47QtF1Bs-x4E8CQ8KcJnU2zRu7RzC320Coe6nEOjqJc=.838f3840-656c-4a47-a664-0ab808e2c811@github.com> On Thu, 21 Apr 2022 12:19:20 GMT, Stefan Karlsson wrote: > had hoped to fine a way to just get rid of it instead of finding a better name. `vmClasses::Reference_klass()->set_reference_type(REF_SOFT);` works. In fact, anything other than `REF_NONE` works. The correct ref-type for each subclass of `Reference` will be set later on in `vmClasses::resolve_all`. Do you think that is better? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ihse at openjdk.java.net Thu Apr 21 15:40:28 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 15:40:28 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> Message-ID: On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs wrote: >> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. >> >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-) @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run? And yes, ideally the tests should be spell checked as well. It's just that: 1) the product source is (imho) more important to begin with, 2) test comments are generally of a lower quality and more likely to contain more typos (imho), meaning even more work for me to publish a PR i believe is correct, and 3) the tests in the JDK are so intertwined and messy that I'm having a hard time understanding what groups to post reviews to. I could make one mega-PR touching the entire test code base, but I doubt it would be very popular. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From kevinw at openjdk.java.net Thu Apr 21 16:21:26 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 21 Apr 2022 16:21:26 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. > > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. All looks good to me, just the invokable which you might want to leave as is, unless there are other strong feelings. 8-) src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38: > 36: jboolean pending; /* Is an invoke requested? */ > 37: jboolean started; /* Is an invoke happening? */ > 38: jboolean available; /* Is the thread in an invocable state? */ invocable could perhaps stay as invokable ? Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change, and I see Internet dictionary evidence of invokable being acceptable. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8334 From dfuchs at openjdk.java.net Thu Apr 21 16:34:29 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 21 Apr 2022 16:34:29 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> Message-ID: On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs wrote: >> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. >> >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > LGTM. I spotted one fix in a exception message. I don't expect that there will be tests depending on that, but it might still be a good idea to run the serviceability tests to double check. Although I guess the test would have had the same typo and would have been fixed too were it the case :-) > @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run? Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution. ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From ihse at openjdk.java.net Thu Apr 21 17:25:23 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 21 Apr 2022 17:25:23 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: On Thu, 21 Apr 2022 16:17:20 GMT, Kevin Walls wrote: >> I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. >> >> >> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). >> >> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. > > src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38: > >> 36: jboolean pending; /* Is an invoke requested? */ >> 37: jboolean started; /* Is an invoke happening? */ >> 38: jboolean available; /* Is the thread in an invocable state? */ > > invocable could perhaps stay as invokable ? > Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change, and I see Internet dictionary evidence of invokable being acceptable. But on the other hand we have `javax.script.Invocable`. :-) Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From kevinw at openjdk.java.net Thu Apr 21 18:11:29 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 21 Apr 2022 18:11:29 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: On Thu, 21 Apr 2022 17:22:04 GMT, Magnus Ihse Bursie wrote: >> src/jdk.jdwp.agent/share/native/libjdwp/invoker.h line 38: >> >>> 36: jboolean pending; /* Is an invoke requested? */ >>> 37: jboolean started; /* Is an invoke happening? */ >>> 38: jboolean available; /* Is the thread in an invocable state? */ >> >> invocable could perhaps stay as invokable ? >> Elsewhere we have a filename com/sun/tools/jdi/InvokableTypeImpl.java which we clearly don't want to change, and I see Internet dictionary evidence of invokable being acceptable. > > But on the other hand we have `javax.script.Invocable`. :-) > > Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". > > But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". > > I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes. Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed. Don't lose sleep over it. 8-) More importantly, on the tests -- I see the changes in exception messages searched for the wrong text in the test directories, and didn't find any matches that looked like checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From cjplummer at openjdk.java.net Thu Apr 21 20:22:22 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 21 Apr 2022 20:22:22 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" Message-ID: The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. ------------- Commit messages: - Fix numerous issues with suspendPolicy008 related to unexpected thread creation. Changes: https://git.openjdk.java.net/jdk/pull/8350/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8350&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285032 Stats: 32 lines in 3 files changed: 14 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/8350.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8350/head:pull/8350 PR: https://git.openjdk.java.net/jdk/pull/8350 From cjplummer at openjdk.java.net Thu Apr 21 20:24:29 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 21 Apr 2022 20:24:29 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> <0_hdhYwL3x6Qo-ukO_JFqVW90XI-LWeKYztV0mrWHl8=.87b15dd4-e447-4e09-9817-89e5a2d34ef9@github.com> Message-ID: On Thu, 21 Apr 2022 16:30:42 GMT, Daniel Fuchs wrote: > > @dfuch I have only updated files in `src`, so if the incorrect spelling is tested, that test will now fail. I'm unfortunately not well versed in what tests cover serviceability code. Can you suggest a suitable set of tests to run? > > Folks from serviceability-dev will be more able to answer that - but I would suggest running tier2-tier3 as a precaution. I sent Magnus a PM with info on all the svc tests that can be run. ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From duke at openjdk.java.net Fri Apr 22 02:41:28 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 22 Apr 2022 02:41:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh src/java.base/share/classes/java/lang/ThreadLocal.java line 179: > 177: private T get(Thread t) { > 178: ThreadLocalMap map = getMap(t); > 179: if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) { Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled. -------------------------------------------------------------------------------- This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does: return initialValue(); -------------------------------------------------------------------------------- Suggestion: if (map != null) { if (map == ThreadLocalMap.NOT_SUPPORTED) { return initialValue(); } src/java.base/share/classes/java/lang/ThreadLocal.java line 423: > 421: * Construct a new map without a table. > 422: */ > 423: ThreadLocalMap() { It?might be?possible for?this to?be?`private`: Suggestion: private ThreadLocalMap() { ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From stefank at openjdk.java.net Fri Apr 22 08:07:29 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 22 Apr 2022 08:07:29 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Using REF_SOFT seems too hacky. If we rewrite the initialization a bit we can make this work. See suggested change in: https://github.com/stefank/jdk/tree/ref-rename https://github.com/stefank/jdk/commit/68161ce45de7d35b81f9cd6414e1e4cdf0c07665 ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 08:26:26 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 08:26:26 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 08:03:42 GMT, Stefan Karlsson wrote: > Using REF_SOFT seems too hacky. Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. // in vmClasses::resolve_all vmClasses::Reference_klass()->set_reference_type(REF_SOFT); // setting ref-type of Soft/Weak/Final/Phantom vmClasses::SoftReference_klass()->set_reference_type(REF_SOFT); ... vmClasses::Reference_klass()->set_reference_type(REF_NONE); I have no particular preference. What does everyone think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From rpressler at openjdk.java.net Fri Apr 22 08:49:46 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Fri, 22 Apr 2022 08:49:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3] In-Reply-To: References: Message-ID: On Sun, 17 Apr 2022 04:57:34 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Refresh >> - Refresh >> - Merge with jdk-19+18 >> - Refresh >> - Initial push > > src/java.base/share/classes/java/lang/StackTraceElement.java line 556: > >> 554: } >> 555: >> 556: static StackTraceElement[] of(StackTraceElement[] stackTrace) { > > Is it intentional that this method is returning a `StackTraceElement[]` instead of `void`. The current implementation just returns back the passed array after operating on each element. Are callers mandated to use the returned array for subsequent operations instead of the passed array? It's just for convenience of use. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kbarrett at openjdk.java.net Fri Apr 22 09:08:25 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 22 Apr 2022 09:08:25 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review > > Using REF_SOFT seems too hacky. > > Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. > > [...] > I have no particular preference. What does everyone think? I also think using REF_SOFT like that is overly hacky. I think there is still a bootstrapping weirdness, whether using REF_REFERENCE or using Stefan's approach. I think Soft/Weak/Final/PhantomReference_klass get constructed with the reftype of Reference_klass (whatever that is), and then have it later updated to the correct value. In that respect REF_OTHER seems better than REF_REFERENCE. So I no longer like the renaming. Getting rid of it entirely with Stefan's approach, they get REF_NONE initially and then set to the proper value; that's far from the worst bootstrapping kludge I've ever seen. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 09:43:45 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 09:43:45 GMT Subject: RFR: 8285364: Use more precise name for ReferenceType::REF_OTHER [v3] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: Remove REF_ enum for java.lang.ref.Reference Signed-off-by: Albert Yang ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/746ff8e3..73f80ea4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=01-02 Stats: 58 lines in 11 files changed: 28 ins; 24 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 22 09:44:48 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Apr 2022 09:44:48 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v2] In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review I have taken the commit from Stefan and updated the title. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From stefank at openjdk.java.net Fri Apr 22 16:04:26 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 22 Apr 2022 16:04:26 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v2] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:04:37 GMT, Kim Barrett wrote: > > > Using REF_SOFT seems too hacky. > > > > > > Just to put all alternatives on the table. The use of `REF_SOFT` is ephemeral. > > [...] > > I have no particular preference. What does everyone think? > > I also think using REF_SOFT like that is overly hacky. > > I think there is still a bootstrapping weirdness, whether using REF_REFERENCE or using Stefan's approach. I think Soft/Weak/Final/PhantomReference_klass get constructed with the reftype of Reference_klass (whatever that is), and then have it later updated to the correct value. In that respect REF_OTHER seems better than REF_REFERENCE. So I no longer like the renaming. Getting rid of it entirely with Stefan's approach, they get REF_NONE initially and then set to the proper value; that's far from the worst bootstrapping kludge I've ever seen. I think we can fix the bootstrapping kludge with something like this: https://github.com/stefank/jdk/commit/e62ddb780730dbb5d6766f882346bf0fcc6cdb59 With this patch, we'll always have the correct _reference_type after the InstanceRefKlass constructor has run. (Patch has not gone through full testing yet) ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From sspitsyn at openjdk.java.net Fri Apr 22 23:44:27 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 22 Apr 2022 23:44:27 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by the serviceability team (`java.instrument java.management.rmi java.management jdk.attach jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd jdk.management.agent jdk.management`), and accepted those changes where it indeed discovered real typos. > > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Hi Magnus, Great job, thank you for doing this! It looks good to me. These findings are pretty interesting. Some are funny and some seems to be typical. Good examples of typical typos are: - double letter instead of single - single or even triple letter instead of double Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8334 From serb at openjdk.java.net Fri Apr 22 23:45:27 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 22 Apr 2022 23:45:27 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 19:24:25 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > add more replaces src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291: > 289: > 290: > 291: static HashMap strcache = HashMap.newHashMap(tscripts.length); This code maintains compatibility with jdk1.4, not necessary to change it. src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815: > 813: } > 814: > 815: Map retval =HashMap.newHashMap(natives.length); missed space after '=' ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From dholmes at openjdk.java.net Sat Apr 23 06:12:29 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 23 Apr 2022 06:12:29 GMT Subject: RFR: 8285366: Fix typos in serviceability In-Reply-To: References: <3BDXgNscMXk8wYsWooUxX0e-jJXTHMCdSBR1nxvrM3U=.3f0ea3bd-2b82-4940-8bf6-cca605d7a183@github.com> Message-ID: On Thu, 21 Apr 2022 18:08:05 GMT, Kevin Walls wrote: >> But on the other hand we have `javax.script.Invocable`. :-) >> >> Codespell suggested this change, and I based my decision to keep it based on [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not even listing "invokable" as an alternate spelling, and that "invocable" has about 3x the number of Google hits than "invokable". >> >> But sure, there is perhaps reason to consider "invokable" an acceptable alternative and keep it. I guess it depends on if you consider the word to be based on "invoke" with a suffix, or a latinized form, like "invocation". >> >> I'll wait a while for others to chime in, otherwise I'll revert the "invokable" changes. > > Sure, I just thought there was enough evidence that invokable is not definitely wrong, even if invocable is more correct and popular, so it's not obvious it should be changed. Don't lose sleep over it. 8-) > > More importantly, on the tests -- I saw the changes in exception messages, searched for the wrong text in the test directories, and didn't find any matches that looked like checks. Invocable, Invokable and Invokeable are all used in practice. We have a mix of invocable and invokable throughout our codebase, with more of the former than the latter - and in prose "invocable" is probably best. ------------- PR: https://git.openjdk.java.net/jdk/pull/8334 From duke at openjdk.java.net Sat Apr 23 14:34:58 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 23 Apr 2022 14:34:58 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - maintains compatibility with jdk1.4 for TextTests - fix missed space after '=' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/4f2d4838..684d1528 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Sat Apr 23 14:35:00 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 23 Apr 2022 14:35:00 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 23:31:41 GMT, Sergey Bylokhov wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> add more replaces > > src/demo/share/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java line 291: > >> 289: >> 290: >> 291: static HashMap strcache = HashMap.newHashMap(tscripts.length); > > This code maintains compatibility with jdk1.4, not necessary to change it. @mrserb done. > src/java.datatransfer/share/classes/java/awt/datatransfer/SystemFlavorMap.java line 815: > >> 813: } >> 814: >> 815: Map retval =HashMap.newHashMap(natives.length); > > missed space after '=' @mrserb done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From alanb at openjdk.java.net Mon Apr 25 13:14:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:14:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Fri, 22 Apr 2022 02:26:50 GMT, ExE Boss wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/java/lang/ThreadLocal.java line 179: > >> 177: private T get(Thread t) { >> 178: ThreadLocalMap map = getMap(t); >> 179: if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) { > > Due?to the?way `setInitialValue` is?implemented, `getMap(t)` will?currently be?called?twice when?`ThreadLocal`s are?disabled. > > -------------------------------------------------------------------------------- > > This?method should?probably be?changed so?that?when `map?==?ThreadLocalMap.NOT_SUPPORTED`, it?simply?does: > > return initialValue(); > > > -------------------------------------------------------------------------------- > > Suggestion: > > if (map != null) { > if (map == ThreadLocalMap.NOT_SUPPORTED) { > return initialValue(); > } It's benign but what you suggest may be clearer - thanks! > src/java.base/share/classes/java/lang/ThreadLocal.java line 423: > >> 421: * Construct a new map without a table. >> 422: */ >> 423: ThreadLocalMap() { > > It?might be?possible for?this to?be?`private`: > Suggestion: > > private ThreadLocalMap() { Yes, this can be private. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 25 13:14:52 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:14:52 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2] In-Reply-To: References: <6uSLs-yLEEpG3NxWv35DZvBZRf3_ccheWX9mEnsd_dc=.080d27e9-702f-498f-a278-78860bf14292@github.com> Message-ID: On Fri, 15 Apr 2022 21:24:58 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > >> 113: } >> 114: >> 115: private Runnable target; > > Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class) Yes, it can. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon Apr 25 13:19:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 25 Apr 2022 13:19:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - Refresh - Refresh - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05 Stats: 104157 lines in 1144 files changed: 94155 ins; 4291 del; 5711 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Mon Apr 25 15:55:26 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 25 Apr 2022 15:55:26 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang src/hotspot/share/oops/instanceKlass.cpp line 441: > 439: > 440: // Allocation > 441: if (parser.is_java_lang_ref_Reference_subclass()) { I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From cjplummer at openjdk.java.net Mon Apr 25 18:58:23 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Apr 2022 18:58:23 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 20:14:49 GMT, Chris Plummer wrote: > The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. > > The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. > > 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: > > nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected > > This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. > > 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. > > 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. Ping! Still need two reviews for this PR. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From cjplummer at openjdk.java.net Mon Apr 25 18:59:25 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 25 Apr 2022 18:59:25 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: <2NIEmT7b4IPCutrOjOnsprzw1C7aZX1-ZHmSfEXg0tc=.2683b1a8-6fed-4121-8ca1-978b0e688178@github.com> On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote: >> During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. >> >> The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: >> >> >> bool NativeInstruction::is_sigill_zombie_not_entrant() { >> return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeIllegalInstruction::insert(address code_pos) { >> *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { >> ... >> if (Assembler::reachable_from_branch_at(verified_entry, dest)) { >> ... >> } else { >> // We use an illegal instruction for marking a method as >> // not_entrant or zombie. >> NativeIllegalInstruction::insert(verified_entry); >> } >> >> >> I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. >> >> Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). >> >> The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment fix. Ping! Still need one more review for this PR. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From stefank at openjdk.java.net Mon Apr 25 19:40:33 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 25 Apr 2022 19:40:33 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 15:51:35 GMT, Coleen Phillimore wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove REF_ enum for java.lang.ref.Reference >> >> Signed-off-by: Albert Yang > > src/hotspot/share/oops/instanceKlass.cpp line 441: > >> 439: >> 440: // Allocation >> 441: if (parser.is_java_lang_ref_Reference_subclass()) { > > I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From lancea at openjdk.java.net Mon Apr 25 20:53:26 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Apr 2022 20:53:26 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push Test changes look good. One question/comment below ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lancea at openjdk.java.net Mon Apr 25 20:53:28 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 25 Apr 2022 20:53:28 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh test/jdk/jdk/internal/vm/Continuation/Basic.java line 327: > 325: > 326: // @Test > 327: public void testPinnedNative() { Are you disabling this test? if so, you can do `@Test(enabled=false)` ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From eosterlund at openjdk.java.net Tue Apr 26 13:51:17 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 26 Apr 2022 13:51:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6] In-Reply-To: References: Message-ID: <3euEQy5Mq4sADeywuO86A4TGzStWEaaRyEHdZRCoPao=.593b7f97-4ce1-44fb-a77d-5677a34ce2a8@github.com> On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push I have done a long and extensive hands-on review of most of the JVM code (excluding most of the JVMTI changes). There is still room for improvements, but I think this is in a good enough shape to be integrated now, plus minus some patches in the ether between the fibers branch and this PR which I'm sure will pop up soon. So this looks good to me. Ship it! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Tue Apr 26 17:27:35 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 26 Apr 2022 17:27:35 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/05781877..0864cb09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05-06 Stats: 582 lines in 34 files changed: 285 ins; 128 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Tue Apr 26 18:19:06 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 26 Apr 2022 18:19:06 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" In-Reply-To: References: Message-ID: <4CBqiDYLs0SCUYh41VBBikNRjlAzFfarDqqooT6jeGw=.2d609e75-416c-4ecf-a2df-b49500f65de7@github.com> On Thu, 21 Apr 2022 20:14:49 GMT, Chris Plummer wrote: > The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. > > The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. > > 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: > > nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected > > This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. > > 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. > > 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. It looks good. I've only requested to add a simple comment. Thanks, Serguei test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventFilters.java line 342: > 340: if (event.toString().contains("ForkJoinPool")) > 341: return true; > 342: As I understand, this is to filter out events for carrier threads. Is it right? If so, it'd be good to add a short comment to make it clear. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8350 From dfuchs at openjdk.java.net Tue Apr 26 19:02:19 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 26 Apr 2022 19:02:19 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770: > 768: synchronized (p) { > 769: DatagramPackets.setLength(p, n); > 770: p.setSocketAddress(sender); Hmmm... For integrity it might be better to call the public `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to `DatagramPackets.setLength(p, n);` will no longer be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Tue Apr 26 19:25:44 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 26 Apr 2022 19:25:44 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: References: Message-ID: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> > The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. > > The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. > > 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: > > nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected > > This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. > > 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. > > 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8350/files - new: https://git.openjdk.java.net/jdk/pull/8350/files/8445f328..936877c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8350&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8350&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8350.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8350/head:pull/8350 PR: https://git.openjdk.java.net/jdk/pull/8350 From cjplummer at openjdk.java.net Tue Apr 26 19:25:45 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 26 Apr 2022 19:25:45 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: <4CBqiDYLs0SCUYh41VBBikNRjlAzFfarDqqooT6jeGw=.2d609e75-416c-4ecf-a2df-b49500f65de7@github.com> References: <4CBqiDYLs0SCUYh41VBBikNRjlAzFfarDqqooT6jeGw=.2d609e75-416c-4ecf-a2df-b49500f65de7@github.com> Message-ID: On Tue, 26 Apr 2022 18:13:40 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventFilters.java line 342: > >> 340: if (event.toString().contains("ForkJoinPool")) >> 341: return true; >> 342: > > As I understand, this is to filter out events for carrier threads. > Is it right? If so, it'd be good to add a short comment to make it clear. Ok. It's fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From darcy at openjdk.java.net Tue Apr 26 22:33:21 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 26 Apr 2022 22:33:21 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces Message-ID: To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). I'll update copyright years before pushing. ------------- Commit messages: - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces Changes: https://git.openjdk.java.net/jdk/pull/8410/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285676 Stats: 76 lines in 40 files changed: 76 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From amenkov at openjdk.java.net Tue Apr 26 22:41:40 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 26 Apr 2022 22:41:40 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote: >> During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. >> >> The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: >> >> >> bool NativeInstruction::is_sigill_zombie_not_entrant() { >> return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeIllegalInstruction::insert(address code_pos) { >> *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { >> ... >> if (Assembler::reachable_from_branch_at(verified_entry, dest)) { >> ... >> } else { >> // We use an illegal instruction for marking a method as >> // not_entrant or zombie. >> NativeIllegalInstruction::insert(verified_entry); >> } >> >> >> I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. >> >> Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). >> >> The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment fix. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From wetmore at openjdk.java.net Tue Apr 26 23:05:58 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 26 Apr 2022 23:05:58 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. The two `java.security` ones LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From amenkov at openjdk.java.net Tue Apr 26 23:23:46 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 26 Apr 2022 23:23:46 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> References: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> Message-ID: On Tue, 26 Apr 2022 19:25:44 GMT, Chris Plummer wrote: >> The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. >> >> The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. >> >> 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: >> >> nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected >> >> This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. >> >> 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. >> >> 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Marked as reviewed by amenkov (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008.java line 421: > 419: try { > 420: ThreadStartRequest tsr = eventRManager.createThreadStartRequest(); > 421: // tsr.addThreadFilter(mainThread); I suppose the fix might be just to uncomment this line. Your solution is more complex, but should work too ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From jjg at openjdk.java.net Tue Apr 26 23:38:42 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 26 Apr 2022 23:38:42 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. src/java.base/share/classes/java/lang/ClassValue.java line 43: > 41: * it can use a {@code ClassValue} to cache information needed to > 42: * perform the message send quickly, for each class encountered. > 43: * @param type of the derived value stylistically, compared to other comments, you are missing an initial "the" ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From smarks at openjdk.java.net Wed Apr 27 01:48:49 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 27 Apr 2022 01:48:49 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. I've looked at the changes in java.util (but not sub packages). They're fine, modulo some minor wording changes. src/java.base/share/classes/java/util/AbstractMap.java line 601: > 599: * {@code Map.entrySet().toArray}. > 600: * > 601: * @param the type of keys maintained Please update to match java.util.Map, which says "the type of keys maintained by this map" src/java.base/share/classes/java/util/AbstractMap.java line 748: > 746: * > 747: * @param the type of keys maintained > 748: * @param the type of mapped values Please update to match Map.Entry, which says simply "the type of key" and "the type of the value" src/java.base/share/classes/java/util/Dictionary.java line 44: > 42: * @param the type of keys > 43: * @param the type of mapped values > 44: * Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From prr at openjdk.java.net Wed Apr 27 04:39:43 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 27 Apr 2022 04:39:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: On Sat, 23 Apr 2022 14:34:58 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - maintains compatibility with jdk1.4 for TextTests > - fix missed space after '=' I'm getting a bit tired of seeing these JDK wide changes with lots of files touched. Delete all changes in desktop from this PR and re-submit them as a separate PR. Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Wed Apr 27 05:18:43 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 27 Apr 2022 05:18:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 04:36:37 GMT, Phil Race wrote: > I'm getting a bit tired of seeing these JDK wide changes with lots of files touched. @prrace I'm also a bit tired of seeing so many amazing mis-use in existed codes in jdk. In some place I even see somebody creates a HashMap with factor = 10. I felt my eyes widen and likes seeing a new world or something, then I suddenly notice that he the writer might not have the ability to use HashMap, but use it just as HashTable. Nevermind. > Delete all changes in desktop from this PR and re-submit them as a separate PR. > > Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. Will do 10+ hours later when I off work. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From alanb at openjdk.java.net Wed Apr 27 06:26:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 06:26:50 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 18:58:23 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > > src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770: > >> 768: synchronized (p) { >> 769: DatagramPackets.setLength(p, n); >> 770: p.setSocketAddress(sender); > > Hmmm... For integrity it might be better to call the public `DatagramPacket::setData(byte[] buf, int offset, int length)` method here now. The additional advantage is that the private access to `DatagramPackets.setLength(p, n);` will no longer be needed. DatagramPackets.setLength is not really new, it's just moved. There's a flaw in DatagramPacket that forces its usage - the details are in JDK-8232817. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From rpressler at openjdk.java.net Wed Apr 27 07:36:00 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 27 Apr 2022 07:36:00 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5] In-Reply-To: References: <3RNoPzJecSfEBdapZpbKMJZG1ep3mVUW1Z5kKNrFYSk=.821824df-3431-437a-b5c8-c4627021d349@github.com> Message-ID: On Mon, 25 Apr 2022 20:48:54 GMT, Lance Andersen wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh > > test/jdk/jdk/internal/vm/Continuation/Basic.java line 327: > >> 325: >> 326: // @Test >> 327: public void testPinnedNative() { > > Are you disabling this test? if so, you can do `@Test(enabled=false)` I updated the test and enabled it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From rehn at openjdk.java.net Wed Apr 27 08:46:55 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 27 Apr 2022 08:46:55 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I have looked mostly on runtime, and to much lesser extent the others parts. There are some loose ends, but nothing major that can't wait, so I think it's time. Looks fine, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Wed Apr 27 09:36:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 27 Apr 2022 09:36:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I've reviewed JDI, JDB and JDWP changes. All look good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From stefank at openjdk.java.net Wed Apr 27 09:52:43 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 27 Apr 2022 09:52:43 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 Similar comments to @fisk. This is what I've been focusing on: * In-depth: gc/, oops/, memory/, utilities/ * Partially: runtime/ * Cleanups: hotspot/ ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From tschatzl at openjdk.java.net Wed Apr 27 10:00:39 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Apr 2022 10:00:39 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 Reviewed changes in gc/, oops/, memory/, partially in runtime/. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From lancea at openjdk.java.net Wed Apr 27 10:37:46 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 27 Apr 2022 10:37:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 I have been through all of the tests and they look good. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Wed Apr 27 10:59:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 10:59:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Hi Joe, just two suggestions about the javax.management changes. Otherwise looks good! src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96: > 94: * > 95: * @param the Java type that instances described by this type must > 96: * have. Instead of "instances" - would it be more correct to say "array elements"? src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60: > 58: * @param the Java type that instances described by this type must > 59: * have. > 60: * I would suggest to say "that values described by this type"... ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From prappo at openjdk.java.net Wed Apr 27 11:13:27 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 27 Apr 2022 11:13:27 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. I note that many years ago you filed JDK-6327933, which I'm currently looking at. If implemented, many of the issues from this PR will be addressed automatically, including those in `java.util.concurrent`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From dfuchs at openjdk.java.net Wed Apr 27 11:38:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 11:38:50 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149: > 147: * access to the file or {@link java.lang.management.ManagementPermission > 148: * ManagementPermission("control")} is denied > 149: * @since 19 Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From coleenp at openjdk.java.net Wed Apr 27 12:39:42 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Apr 2022 12:39:42 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: <7ERXZAkg8hiuWewX3W3dd1fBK1mN3TjY0YxSiOcztxQ=.17f8cb74-753d-4220-ad00-55495f6ce657@github.com> On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang I think this is better. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8332 From coleenp at openjdk.java.net Wed Apr 27 12:39:43 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 27 Apr 2022 12:39:43 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 19:36:49 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 441: >> >>> 439: >>> 440: // Allocation >>> 441: if (parser.is_java_lang_ref_Reference_subclass()) { >> >> I'm having a really hard time understanding this. java.lang.Reference now doesn't have any REF_OTHER type set. I didn't realize that a java.lang.Reference instance is a plain InstanceKlass, and not an InstanceRefKlass. Is this right? > > Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. Yeah, please add a short comment in the is_java_lang_ref_Reference_subclass function that this is the case, now that we've learned this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From alanb at openjdk.java.net Wed Apr 27 13:44:13 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 13:44:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> References: <-PrU1VXjpfCBPL6p9DQaFDv5GcKHWWDLkh1gF5E1Vdk=.223612b6-8044-4c33-84ef-1634e80c2e0c@github.com> Message-ID: On Wed, 27 Apr 2022 11:34:51 GMT, Daniel Fuchs wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > > src/jdk.management/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java line 149: > >> 147: * access to the file or {@link java.lang.management.ManagementPermission >> 148: * ManagementPermission("control")} is denied >> 149: * @since 19 > > Maybe there ought to be an `@throws UnsupportedOperationException` here since that is what the default implementation of the method is supposed to do. Well spotted. The implSpec further up documents it but it should be in the throws list too. > test/jdk/java/net/vthread/HttpALot.java line 76: > >> 74: var address = server.getAddress(); >> 75: URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello"); >> 76: > > Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated. A few of these tests started out as standalone classes that could be run without test infrastructure. This one, and InterruptHttp, can be easily changed to use the URIBuilder infra library, so we can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Wed Apr 27 13:44:14 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 13:44:14 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 test/jdk/java/net/vthread/HttpALot.java line 76: > 74: var address = server.getAddress(); > 75: URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/hello"); > 76: Nit: Ideally we should use the URIBuilder from the test library here, and the IP literal address to improve stability of the test on machines that may have strange /etc/hosts configuration. This can be taken care of after this PR has been integrated. test/jdk/java/net/vthread/InterruptHttp.java line 88: > 86: InetAddress lb = InetAddress.getLoopbackAddress(); > 87: listener = new ServerSocket(0, -1, lb); > 88: address = "http://" + lb.getHostAddress() + ":" + listener.getLocalPort(); Same remark about using URIBuilder here. It would take care of properly formatting the address in case of IPv6 literals. This can be taken care of after this PR has been integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 27 14:24:20 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 14:24:20 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/0864cb09..f2ed4f9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06-07 Stats: 505 lines in 15 files changed: 139 ins; 189 del; 177 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From ayang at openjdk.java.net Wed Apr 27 14:31:59 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 27 Apr 2022 14:31:59 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 12:35:56 GMT, Coleen Phillimore wrote: >> Yes, I was also surprised by this. The java.lang.ref.Reference Klass is only an InstanceKlass, not an InstanceRefKlass. > > Yeah, please add a short comment in the is_java_lang_ref_Reference_subclass function that this is the case, now that we've learned this. Instead of documenting this surprise, how about removing it by extending this method to cover all subtypes of `j.l.r.Reference`? bool ClassFileParser::is_java_lang_ref_Reference_or_subclass() const { if (_super_klass == NULL) { return false; } if (_class_name == vmSymbols::java_lang_ref_Reference()) { return true; } if (_super_klass->name() == vmSymbols::java_lang_ref_Reference()) { return true; } return _super_klass->reference_type() != REF_NONE; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From dfuchs at openjdk.java.net Wed Apr 27 14:36:07 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 27 Apr 2022 14:36:07 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <-DAfgDmuhsODNWuhCRea8JMYvDS4Gq6fX1kmESiMDss=.37b60329-a65f-4ab9-a78c-79db99f80226@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Thanks for the refresh Alan! Things look good to me now. I have gone over java.io, the networking parts of java.nio, java.net, and the JMX related changes. For what I have reviewed, I believe this is good to go. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Wed Apr 27 14:43:11 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 27 Apr 2022 14:43:11 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed jvmti changes, hotspot tests (excluding tests modified by lmesnik), jdk svc tests changes. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From dcubed at openjdk.java.net Wed Apr 27 17:12:29 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 27 Apr 2022 17:12:29 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I've reviewed the JVM/TI, JDWP and JDI changes and I'm good with those. I haven't reviewed the JDB changes (forgot about those) and I have not (yet) reviewed the Runtime changes. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From kevinw at openjdk.java.net Wed Apr 27 17:12:29 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 27 Apr 2022 17:12:29 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Been through the JDI changes and jdb/example code. Built and manually tested some operations with jdb observing virtual threads. Been through jdk.management/share/classes/com/sun/management and also manually tested jconsole attaching (e.g. dumpThreads operation in both TEXT_PLAIN and JSON). ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 17:30:06 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 17:30:06 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: > 56: > 57: // maps a class to the hashes of stack traces pinned by that code in that class > 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); Can you use `ClassValue` in this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From amenkov at openjdk.java.net Wed Apr 27 17:48:55 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Apr 2022 17:48:55 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed debugger-related code (JDI/JDWP/JDB/tests) and partially JVMTI. ------------- Marked as reviewed by amenkov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 17:55:23 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 17:55:23 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: > 120: */ > 121: > 122: public static final int SCOPED_CACHE_SHIFT; I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Wed Apr 27 17:58:47 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Apr 2022 17:58:47 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: References: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> Message-ID: On Tue, 26 Apr 2022 23:20:19 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008.java line 421: > >> 419: try { >> 420: ThreadStartRequest tsr = eventRManager.createThreadStartRequest(); >> 421: // tsr.addThreadFilter(mainThread); > > I suppose the fix might be just to uncomment this line. > Your solution is more complex, but should work too I don't think that filter is correct. ThreadStartEvents are always delivered on the thread that is starting. Adding a thread filter for "main" is going to result in never finding a matching ThreadStartEvent since "main" has already started and it won't match any of the newly started threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From cjplummer at openjdk.java.net Wed Apr 27 18:00:39 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Apr 2022 18:00:39 GMT Subject: RFR: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." [v2] In-Reply-To: References: Message-ID: On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote: >> During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. >> >> The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: >> >> >> bool NativeInstruction::is_sigill_zombie_not_entrant() { >> return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeIllegalInstruction::insert(address code_pos) { >> *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead >> } >> >> void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { >> ... >> if (Assembler::reachable_from_branch_at(verified_entry, dest)) { >> ... >> } else { >> // We use an illegal instruction for marking a method as >> // not_entrant or zombie. >> NativeIllegalInstruction::insert(verified_entry); >> } >> >> >> I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. >> >> Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). >> >> The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor comment fix. Thanks for the reviews Alex and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From cjplummer at openjdk.java.net Wed Apr 27 18:00:39 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Apr 2022 18:00:39 GMT Subject: Integrated: 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 22:16:36 GMT, Chris Plummer wrote: > During the SA attach process on macOS, SA installs an exception handler and expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found if I changed the code to just ignore this, it eventually gets the EXC_SOFTWARE exception and everything is fine. > > The EXC_BAD_INSTRUCTION is from the following code in the JIT and is expected behavior: > > > bool NativeInstruction::is_sigill_zombie_not_entrant() { > return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeIllegalInstruction::insert(address code_pos) { > *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead > } > > void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { > ... > if (Assembler::reachable_from_branch_at(verified_entry, dest)) { > ... > } else { > // We use an illegal instruction for marking a method as > // not_entrant or zombie. > NativeIllegalInstruction::insert(verified_entry); > } > > > I fixed SA to retry each time it gets EXC_BAD_INSTRUCTION. I also did the same for EXC_BAD_ACCESS. We saw this once on x64, and it looks like it is for a trap-based NPE, given that the bad address that was provided as part of the exception data is for address 0x8. > > Although the fix is somewhat straight forward, the context in which it is run is not. SA does a `ptrace_attach()`. This seems to result in a SIGSTOP being generated. SA provides an exception handler called `catch_mach_exception_raise()`. It gets called for any pending exception when SA calls `mach_msg(&exc_msg.header, MACH_RCV_MSG, ...)` from `wait_for_exception()`. So `catch_mach_exception_raise()` should see the SIGSTOP, return KERN_SUCCESS (which means to ignore the exception), and then `mach_msg()` returns to `wait_for_exception()`, which checks for success of having received the SIGSTOP, and then allows SA to continue with its attach process (like suspending all threads). > > The details of attaching and exception handling are actually much uglier than that, and I don't pretend to even understand half of it. https://www.spaceflint.com/?p=150 is an interesting read if you are looking for more details. This pull request has now been integrated. Changeset: 716a80a8 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/716a80a8385776975c5aa58c0c757f01285e8ab5 Stats: 40 lines in 1 file changed: 25 ins; 0 del; 15 mod 8283179: SA tests fail with "ERROR: catch_mach_exception_raise: Message doesn't denote a Unix soft signal." Reviewed-by: dholmes, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8255 From mchung at openjdk.java.net Wed Apr 27 18:11:08 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 18:11:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.management/share/classes/sun/management/ThreadImpl.java line 447: > 445: if (threads != null) { > 446: long[] tids = Stream.of(threads) > 447: .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread)) Returning an array of thread IDs of just the platform threads is good. The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...." ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 18:21:13 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 18:21:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 17:27:56 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: > >> 56: >> 57: // maps a class to the hashes of stack traces pinned by that code in that class >> 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); > > Can you use `ClassValue` in this case? I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mchung at openjdk.java.net Wed Apr 27 18:21:13 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 18:21:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 18:13:15 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58: >> >>> 56: >>> 57: // maps a class to the hashes of stack traces pinned by that code in that class >>> 58: private static final Map, Hashes> classToHashes = new WeakHashMap<>(); >> >> Can you use `ClassValue` in this case? > > I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. It's not critical and no problem if this is cleaned up as a follow-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dlong at openjdk.java.net Wed Apr 27 19:11:17 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 27 Apr 2022 19:11:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From amenkov at openjdk.java.net Wed Apr 27 19:24:42 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 27 Apr 2022 19:24:42 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: References: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> Message-ID: On Wed, 27 Apr 2022 17:55:35 GMT, Chris Plummer wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008.java line 421: >> >>> 419: try { >>> 420: ThreadStartRequest tsr = eventRManager.createThreadStartRequest(); >>> 421: // tsr.addThreadFilter(mainThread); >> >> I suppose the fix might be just to uncomment this line. >> Your solution is more complex, but should work too > > I don't think that filter is correct. ThreadStartEvents are always delivered on the thread that is starting. Adding a thread filter for "main" is going to result in never finding a matching ThreadStartEvent since "main" has already started and it won't match any of the newly started threads. Oh, yeah. You are right. ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From alanb at openjdk.java.net Wed Apr 27 19:25:53 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 19:25:53 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 17:53:01 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: > >> 120: */ >> 121: >> 122: public static final int SCOPED_CACHE_SHIFT; > > I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it. > src/java.management/share/classes/sun/management/ThreadImpl.java line 447: > >> 445: if (threads != null) { >> 446: long[] tids = Stream.of(threads) >> 447: .filter(t -> !(t instanceof jdk.internal.misc.CarrierThread)) > > Returning an array of thread IDs of just the platform threads is good. The javadoc needs to be updated to say "Returns an array of thread identifiers for the platform threads...." I think you mean the comment on the private method. Yes, that could be clearer that it just returns platform threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dlong at openjdk.java.net Wed Apr 27 19:46:58 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 27 Apr 2022 19:46:58 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e The compiler changes look good to me. Marked as reviewed by dlong (Reviewer). ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Wed Apr 27 19:46:59 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 27 Apr 2022 19:46:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <-k-fd3inPeP7D7elq5T4NOXMUrScsScjLsBqx3q6ucI=.37b4419d-32f1-48af-9c41-09979ca578ce@github.com> On Wed, 27 Apr 2022 18:16:54 GMT, Mandy Chung wrote: >> I was wondering that too, but held off commenting since it's not super performance critical given `classToHashes` is synchronized on. However, it does make the code a little clearer. > > It's not critical and no problem if this is cleaned up as a follow-up. Good idea, this could be improved. As Paul says, it's not performance critical as this is a diagnostic option for printing the stack trace when pinned. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 19:47:01 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 19:47:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45: > 43: * threads is unbounded. > 44: */ > 45: class ThreadPerTaskExecutor implements ExecutorService { This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`. `SharedThreadContainer` supports a number of different shared container policies that could be made clearer. Architecturally i think this could be better layered but it can be iterated on later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 20:14:59 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 20:14:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <7hqD-RqcX58pubiORXgyjVjuyg_-yi1NZqJ8CJIPH20=.480769c3-4033-4741-904d-10c77de38cc4@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/java.base/share/classes/java/lang/Thread.java line 116: > 114: * carrier threads. Locking and I/O operations are examples of operations > 115: * where a carrier thread may be re-scheduled from one virtual thread to another. > 116: * Code executing in a virtual thread is not aware of underlying carrier thread. Suggestion: * Code executing in a virtual thread is not aware of the underlying carrier thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Wed Apr 27 20:29:48 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Apr 2022 20:29:48 GMT Subject: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" [v2] In-Reply-To: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> References: <4SFfKfb8u-jVogYdJkfsC8LI6TftpBzD1yQLAMzrbgs=.53c44bd1-cd05-4913-b4d3-bac63406f0da@github.com> Message-ID: On Tue, 26 Apr 2022 19:25:44 GMT, Chris Plummer wrote: >> The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. >> >> The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. >> >> 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: >> >> nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected >> >> This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. >> >> 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. >> >> 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Thanks for the reviews Alex and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From cjplummer at openjdk.java.net Wed Apr 27 20:42:47 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 27 Apr 2022 20:42:47 GMT Subject: Integrated: 8285032: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 20:14:49 GMT, Chris Plummer wrote: > The test is testing that EventSets for ThreadStartEvents have the proper suspendPolicy. When there is more than one ThreadStartRequest and a thread is started, each ThreadStartRequest results in a ThreadStartEvent being created, and they all are grouped into the same EventSet. The suspendPolicy on this EventSet should come from the ThreadStartRequest suspend policy that suspends the most threads. The test is testing for all possible combinations of the 3 suspend polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the resulting suspend policy should be ALL. > > The following 3 issues are being addressed. These all turned up in loom as a result of carrier threads being created while the test was running, but potentially could happen with other threads that the jvm starts up. > > 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes gets one that is for a carrier thread. In general this is not a problem because the test will accept any thread, but sometimes this carrier thread is generated between setting up two different `ThreadStartRequests`, and as a result has the wrong suspend policy, so the test fails with: > > nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != policyExpected > > This is fixed by using getEventSetForThreadStartDeath() instead of getEventSet(), so carrier threads (and any other spuriously created thread) can be ignored. > > 2. The ThreadStartRequests used a filterCount of 1, which meant they would only produce one ThreadStartEvent. This meant that after fix (1) was in place, I started seeing issues with not even seeing the expected ThreadStartEvent, because the 1 count was used up by the carrier thread starting. I don't see any reason for this filterCount (other than the issue described in 3), so I just removed it. > > 3. After (1) and (2) were in place, I then noticed issues with sometimes getting a ThreadStartEvent when the BreakpointEvent was expected. This is because sometime a carrier thread was being created after receiving the expected ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is the result of getting rid of the counterFiler). This was fixed by having breakpointForCommunication() filter out unexpected ThreadStartEvents by calling EventFilters.filtered(). I also had to add carrier threads that EventFilters.filtered() filters out. This pull request has now been integrated. Changeset: 5c093493 Author: Chris Plummer URL: https://git.openjdk.java.net/jdk/commit/5c0934931b097baf76c1f6a25f0c0b73af45ffc3 Stats: 33 lines in 3 files changed: 15 ins; 2 del; 16 mod 8285032: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with "eventSet.suspendPolicy() != policyExpected" Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8350 From mchung at openjdk.java.net Wed Apr 27 22:31:07 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 27 Apr 2022 22:31:07 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I reviewed most of the source files in `java.base` except `java.util.concurrent`. I also reviewed `java.logging`, `java.management` and `jdk.management` modules. The changes are easy to follow and clean. Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Wed Apr 27 22:43:45 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 27 Apr 2022 22:43:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e It's great to see end game in play for this multi-year effort, impressive work by all involved. I looked through code in the base module. Generally looks well structured and documented. The fork join code is naturally hard to review. I did try! (it takes the prize for the highest Java code density in the JDK). I mostly looked for regular and repeated structure rather than trying to fully understand/review the intricate concurrency details. IMO there is some post integration work to do around the architecture of thread containers, i presume the structured concurrency implementation (use of thread flock) will help with that. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From bpb at openjdk.java.net Wed Apr 27 23:10:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 27 Apr 2022 23:10:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <3XCjG_IelbjoKjjlqgOq0me4CmVTvVNP-cUMgi2W8V4=.53a46e15-552c-4962-a620-5d97a85c138d@github.com> On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e The changes to the `java.io` package and related files in `libjava`, and the changes to the non-networking parts of the `java.nio.channels`, `sun.nio.ch`, and `sun.nio.fs` packages and related files in `libnio` all look fine to me. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From darcy at openjdk.java.net Wed Apr 27 23:10:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:10:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 01:39:27 GMT, Stuart Marks wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > src/java.base/share/classes/java/util/AbstractMap.java line 601: > >> 599: * {@code Map.entrySet().toArray}. >> 600: * >> 601: * @param the type of keys maintained > > Please update to match java.util.Map, which says "the type of keys maintained by this map" I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. > src/java.base/share/classes/java/util/Dictionary.java line 44: > >> 42: * @param the type of keys >> 43: * @param the type of mapped values >> 44: * > > Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Wed Apr 27 23:15:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:15:42 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:54:00 GMT, Daniel Fuchs wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > src/java.management/share/classes/javax/management/openmbean/ArrayType.java line 96: > >> 94: * >> 95: * @param the Java type that instances described by this type must >> 96: * have. > > Instead of "instances" - would it be more correct to say "array elements"? Will change to "the Java component type that arrays described by ArrayType must have" ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Wed Apr 27 23:21:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:21:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8285676 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/fe47dd2f..e0ac5dcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00-01 Stats: 5958 lines in 128 files changed: 4827 ins; 485 del; 646 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Wed Apr 27 23:21:52 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 27 Apr 2022 23:21:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 10:55:22 GMT, Daniel Fuchs wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Respond to review feedback. >> - Merge branch 'master' into JDK-8285676 >> - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces > > src/java.management/share/classes/javax/management/openmbean/SimpleType.java line 60: > >> (failed to retrieve contents of file, check the PR for context) > I would suggest to say "that values described by this type"... Will change to "the Java type that values described by this SimpleType must have." ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From smarks at openjdk.java.net Wed Apr 27 23:31:55 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 27 Apr 2022 23:31:55 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:04:47 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/util/AbstractMap.java line 601: >> >>> 599: * {@code Map.entrySet().toArray}. >>> 600: * >>> 601: * @param the type of keys maintained >> >> Please update to match java.util.Map, which says "the type of keys maintained by this map" > > I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map". >> src/java.base/share/classes/java/util/Dictionary.java line 44: >> >>> 42: * @param the type of keys >>> 43: * @param the type of mapped values >>> 44: * >> >> Urgh. This class is obsolete, but it was retrofitted to implement Map and was subsequently generified, so I'd update these to match java.util.Map. > > The javadoc of Dictionary states "The Dictionary class [...] maps keys to values." which was my guide for the wording, but I don't mind changing it. My bad, `Dictionary` was not retrofitted to implement `Map` but it gained `K` and `V` type parameters to align with `Map`. No need to change this; it doesn't really matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From lmesnik at openjdk.java.net Wed Apr 27 23:57:00 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 27 Apr 2022 23:57:00 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class Message-ID: The test failed if GC happens somewhere between Class c = Class.forName("TestClass", true, dummyloader); and OutputAnalyzer output = executor.execute("VM.classloader_stats"); The fix is to make hc static as Chris proposed. To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats"); ------------- Commit messages: - fix Changes: https://git.openjdk.java.net/jdk/pull/8438/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278123 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8438/head:pull/8438 PR: https://git.openjdk.java.net/jdk/pull/8438 From coleenp at openjdk.java.net Thu Apr 28 00:31:46 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 28 Apr 2022 00:31:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I've reviewed the new files in Hotspot runtime and the cpu directories, as well as the changes to existing files in runtime, oops, utilities, interpreter and classfile. I'm happy to approve this PR. Thank you to everyone for their hard work in reviewing this code, and well done to @pron and @AlanBateman and all the loom team for bringing us this significant and exciting new feature for Java! src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388: > 2386: } > 2387: > 2388: void @sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration. It looks so strange. I noticed that it's pre-existing for other functions in this file. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Thu Apr 28 00:47:41 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 28 Apr 2022 00:47:41 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:49:56 GMT, Leonid Mesnik wrote: > The test failed if GC happens somewhere between > Class c = Class.forName("TestClass", true, dummyloader); > and > OutputAnalyzer output = executor.execute("VM.classloader_stats"); > > The fix is to make hc static as Chris proposed. > > To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats"); test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java line 178: > 176: static { > 177: try { > 178: // Create a hidden class, keep reference in the case if GC happens "Create a hidden class. Keep a reference in case a GC happens." I hadn't noticed the original comment when first suggesting making the Class reference static. I wonder what was meant by "non-strong class". ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From lmesnik at openjdk.java.net Thu Apr 28 00:52:42 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 28 Apr 2022 00:52:42 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 00:44:18 GMT, Chris Plummer wrote: >> The test failed if GC happens somewhere between >> Class c = Class.forName("TestClass", true, dummyloader); >> and >> OutputAnalyzer output = executor.execute("VM.classloader_stats"); >> >> The fix is to make hc static as Chris proposed. >> >> To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats"); > > test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java line 178: > >> 176: static { >> 177: try { >> 178: // Create a hidden class, keep reference in the case if GC happens > > "Create a hidden class. Keep a reference in case a GC happens." > > I hadn't noticed the original comment when first suggesting making the Class reference static. I wonder what was meant by "non-strong class". This line added by 8238358: Implementation of JEP 371: Hidden Classes which has many co-authors. Hope someone could provide an explanation during this review. It might be possible that the goal was to verify that VM.classloader_stats provide might provide info for non-reachable clasees. However it makes test to fragile, since can't block class unloading now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From darcy at openjdk.java.net Thu Apr 28 01:34:19 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/e0ac5dcb..db4919a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From prr at openjdk.java.net Thu Apr 28 01:34:19 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:31:13 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 01:34:19 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 01:34:19 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 23:24:57 GMT, Stuart Marks wrote: >> I said "keys maintained", omitting "by this map" to finesse the question of if the SimpleEntry class *is* a map, or is used to implement a map, etc. I can change it to include "by this map" if the map/entry distinction is okay to be blurred. > > Whoops, sorry, this is `SimpleEntry`, which is _not_ a `Map`. In this case I'd follow `Map.Entry` which says "the type of the key" and "the type of the map". Will change to the Map.Entry wording "the type of key" and "the type of the value", respectively. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From sspitsyn at openjdk.java.net Thu Apr 28 02:24:53 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 28 Apr 2022 02:24:53 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:00:52 GMT, Coleen Phillimore wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388: > >> 2386: } >> 2387: >> 2388: void > > @sspitsyn We should clean up this aberrant style of putting the return type on the line before the rest of the function declaration after this integration. It looks so strange. I noticed that it's pre-existing for other functions in this file. I'm okay to follow any style. We can do it after the integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Thu Apr 28 04:49:41 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 28 Apr 2022 04:49:41 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 00:49:03 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java line 178: >> >>> 176: static { >>> 177: try { >>> 178: // Create a hidden class, keep reference in the case if GC happens >> >> "Create a hidden class. Keep a reference in case a GC happens." >> >> I hadn't noticed the original comment when first suggesting making the Class reference static. I wonder what was meant by "non-strong class". > > This line added by 8238358: Implementation of JEP 371: Hidden Classes which has many co-authors. Hope someone could provide an explanation during this review. > > It might be possible that the goal was to verify that VM.classloader_stats provide might provide info for non-reachable clasees. However it makes test to fragile, since can't block class unloading now. Yes, that seems to be the case, and you are right that it is not something that is safe to assume. ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From smarks at openjdk.java.net Thu Apr 28 05:29:56 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 28 Apr 2022 05:29:56 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Reviewed java.io, java.lang, java.lang.ref. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 28 07:23:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 07:23:50 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: References: Message-ID: <5BL2ETPi-kD_QUBOiwE2HqQUPXfdD9mLttEYWhBfW9Q=.1891a298-2eaf-45e9-8201-2be5dbe9b867@github.com> On Thu, 28 Apr 2022 04:46:35 GMT, Chris Plummer wrote: >> This line added by 8238358: Implementation of JEP 371: Hidden Classes which has many co-authors. Hope someone could provide an explanation during this review. >> >> It might be possible that the goal was to verify that VM.classloader_stats provide might provide info for non-reachable clasees. However it makes test to fragile, since can't block class unloading now. > > Yes, that seems to be the case, and you are right that it is not something that is safe to assume. Lookup.defineHiddenClass allows class options to be specified, one of which is "STRONG" to mean that the hidden class can't unloaded if its defining loader is reachable. A static reference or a reachability fence should work for this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From dholmes at openjdk.java.net Thu Apr 28 07:23:51 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 07:23:51 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: <5BL2ETPi-kD_QUBOiwE2HqQUPXfdD9mLttEYWhBfW9Q=.1891a298-2eaf-45e9-8201-2be5dbe9b867@github.com> References: <5BL2ETPi-kD_QUBOiwE2HqQUPXfdD9mLttEYWhBfW9Q=.1891a298-2eaf-45e9-8201-2be5dbe9b867@github.com> Message-ID: On Thu, 28 Apr 2022 07:16:05 GMT, Alan Bateman wrote: >> Yes, that seems to be the case, and you are right that it is not something that is safe to assume. > > Lookup.defineHiddenClass allows class options to be specified, one of which is "STRONG" to mean that the hidden class can't unloaded if its defining loader is reachable. > > A static reference or a reachability fence should work for this test. By default hidden classes are non-strong and can be unloaded when no longer referenced, even if their classloader is still reachable. As you want the hidden class to stick around so it can be reported in the stats then either keep a reference (as you have) or else create it as a STRONG hidden class. ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From aph at openjdk.java.net Thu Apr 28 07:46:45 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 28 Apr 2022 07:46:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:21:58 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java line 122: >> >>> 120: */ >>> 121: >>> 122: public static final int SCOPED_CACHE_SHIFT; >> >> I can't find this constant being used. If added for future, maybe keep `UnsafeConstants` class and this static field package-private for now. > > It originally configured the number of lines in extent local cache but the implementation has changed. @theRealAph would be best to comment on this, it may be possible to delete it. Yes, it's dead. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 28 07:52:58 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 07:52:58 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:43:22 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java line 45: > >> 43: * threads is unbounded. >> 44: */ >> 45: class ThreadPerTaskExecutor implements ExecutorService { > > This class manages the set of per-task threads which arguably should be the job of the thread container, and it awkwardly overrides the container's set of threads by setting a field on `SharedThreadContainer.threadsSupplier`. > > `SharedThreadContainer` supports a number of different shared container policies that could be made clearer. > > Architecturally i think this could be better layered but it can be iterated on later. Indeed, the layering is a bit awkward and I plan to replace it. It came about as a short term solution to avoid double bookkeeping of virtual threads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dfuchs at openjdk.java.net Thu Apr 28 08:03:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 28 Apr 2022 08:03:43 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Thanks for the updates Joe. Your new wording looks good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410 From alanb at openjdk.java.net Thu Apr 28 08:14:25 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 08:14:25 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55: > 53: * against the original path of the directory (irrespective of if the > 54: * directory is moved since it was opened). > 55: * @param the type of path It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead? src/java.base/share/classes/java/nio/file/WatchEvent.java line 51: > 49: /** > 50: * An event kind, for the purposes of identification. > 51: * @param the type of the context value This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From ayang at openjdk.java.net Thu Apr 28 09:15:33 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 09:15:33 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - comment - Rework reference type initialization Signed-off-by: Albert Yang ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/73f80ea4..e4f6a66a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=02-03 Stats: 57 lines in 7 files changed: 50 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 28 09:15:34 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 09:15:34 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v3] In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 09:43:45 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove REF_ enum for java.lang.ref.Reference > > Signed-off-by: Albert Yang I have taken "Rework reference type initialization" from Stefan and added comments on a potential surprise that `j.l.r.Reference` is `instanceKlass` not `instanceRefKlass`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Thu Apr 28 09:47:24 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 28 Apr 2022 09:47:24 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment Message-ID: Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. ------------- Commit messages: - Use JavaThread::current_or_null - Do not call JavaThread::thread_from_jni_environment Changes: https://git.openjdk.java.net/jdk/pull/8446/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285794 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From kbarrett at openjdk.java.net Thu Apr 28 11:17:44 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 28 Apr 2022 11:17:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 09:15:33 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - comment > - Rework reference type initialization > > Signed-off-by: Albert Yang There are further cleanups possible if we didn't have REF_NONE and InstanceKlass didn't have a reference type. But there are a number of uses of InstanceKlass::reference_type. Doing anything along those lines (assuming it's deemed worthwhile to do so) can be done in a followup RFE. src/hotspot/share/classfile/classFileParser.cpp line 6098: > 6096: > 6097: return _super_klass->reference_type() != REF_NONE; > 6098: } Stylistically, I'd prefer an if-ladder here. I might also swap the reference-type check and the name check, so the for-bootstrapping name check case being last (with a comment to that effect). src/hotspot/share/oops/instanceKlass.cpp line 497: > 495: _nest_host_index(0), > 496: _init_state(allocated), > 497: _reference_type(REF_NONE), This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. src/hotspot/share/oops/instanceKlass.hpp line 580: > 578: protected: > 579: // Only used by the InstanceRefKlass constructor > 580: void set_reference_type(ReferenceType t) { This function wouldn't be needed at all if the reference type was properly initialized. src/hotspot/share/oops/instanceRefKlass.cpp line 55: > 53: } > 54: > 55: // Bootstrapping: this is either of the four direct subclasses of java.lang.ref.Reference s/either of the four/one of the/. In particular remove "four" else, someday, finalization will finally be GC'd and this comment will need to be noticed and updated. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8332 From dholmes at openjdk.java.net Thu Apr 28 11:26:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 11:26:00 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 09:38:30 GMT, Johannes Bechberger wrote: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Changes requested by dholmes (Reviewer). src/hotspot/share/prims/forte.cpp line 566: > 564: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { > 565: > 566: JavaThread* thread = JavaThread::current_or_null(); As this can be in a signal handling context it needs to be Thread::current_or_null_safe(). src/hotspot/share/prims/forte.cpp line 568: > 566: JavaThread* thread = JavaThread::current_or_null(); > 567: > 568: if (trace->env_id == NULL || thread == NULL || thread->is_terminated() || thread->is_exiting()) { `is_exiting()` also covers `is_terminated()`. src/hotspot/share/prims/forte.cpp line 580: > 578: } > 579: > 580: assert(thread == JavaThread::thread_from_jni_environment(trace->env_id), Please add a comment before the assert: // This is safe now as the thread has not terminated and so no VM exit check occurs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From dholmes at openjdk.java.net Thu Apr 28 11:26:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 11:26:02 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:15:34 GMT, David Holmes wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > src/hotspot/share/prims/forte.cpp line 566: > >> 564: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) { >> 565: >> 566: JavaThread* thread = JavaThread::current_or_null(); > > As this can be in a signal handling context it needs to be Thread::current_or_null_safe(). Also please add a comment before this: // Can't use thread_from_jni_environment as it may also perform a VM exit check that is unsafe to // do from this context. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Thu Apr 28 11:38:32 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 28 Apr 2022 11:38:32 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use Thread::current_or_null_safe() and add comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8446/files - new: https://git.openjdk.java.net/jdk/pull/8446/files/28180bc9..1e2885e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=00-01 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From dholmes at openjdk.java.net Thu Apr 28 13:23:38 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 28 Apr 2022 13:23:38 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:38:32 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Use Thread::current_or_null_safe() and add comments Changes requested by dholmes (Reviewer). src/hotspot/share/prims/forte.cpp line 35: > 33: #include "runtime/frame.inline.hpp" > 34: #include "runtime/javaCalls.hpp" > 35: #include "runtime/thread.hpp" You don't need this as you already include the thread.inline.hpp which has to include thread.hpp. src/hotspot/share/prims/forte.cpp line 571: > 569: Thread* raw_thread = Thread::current_or_null_safe(); > 570: > 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { use `rawThread->as_JavaThread()` not a plain cast. src/hotspot/share/prims/forte.cpp line 577: > 575: } > 576: > 577: JavaThread* thread = (JavaThread*)raw_thread; use `rawThread->as_JavaThread()` not a plain cast. You could also incorporate this into the earlier code so you don't do it twice. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From egahlin at openjdk.java.net Thu Apr 28 14:47:16 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 28 Apr 2022 14:47:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168: > 166: assert(!tl->is_excluded(), "invariant"); > 167: if (virtual_thread) { > 168: // TODO: blob cache for virtual threads Fix this now or after integration? src/hotspot/share/jfr/metadata/metadata.xml line 121: > 119: thread="true" stackTrace="true"> > 120: > 121: "Continuation class" = >" Continuation Class" numFrames = frames numRefs = references "Number of interpreted frames" => "Interpreted Frames" "Number of references" => "References" "Stack size in bytes" => "Stack Size" contentType"bytes" src/hotspot/share/jfr/metadata/metadata.xml line 130: > 128: thread="true" stackTrace="true"> > 129: > 130: contClass => continuationClass "Continuation class" => "Continuation Class" "Class of the continuation" Remove (not needed) "Number of interpreted frames" => "Interpreted Frames" numFrames => frames "Number of references" => "References" numRefs => references "Stack size in bytes" => "Stack Size" contentType="bytes" src/hotspot/share/jfr/metadata/metadata.xml line 138: > 136: > 137: > 138: "Allocated new" => "Allocated New" src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94: > 92: static const size_t global_buffer_size = 512 * K; > 93: > 94: static const size_t thread_local_buffer_prealloc_count = 32; Why is more memory needed? Moore's law or something specific to virtual threads? src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81: > 79: be_writer.write(size); > 80: be_writer.write(time); > 81: be_writer.write(JfrTicks::now().value() - time); Why is this changed? src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread end") "Virtual thread end" => "Virtual Thread End" Remove description. src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread pinned") "Virtual thread pinned" => "Virtual Thread Pinned" Remove description src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread start") "virtual thread start" => "Virtual Thread Start" Remove description src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: > 33: > 34: @Category({"Java Runtime"}) > 35: @Label("Virtual thread submit task failed") The label is a bit a long, would "Virtual Thread Submit Failed" work? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mgronlun at openjdk.java.net Thu Apr 28 15:06:01 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:06:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:37:22 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp line 81: > >> 79: be_writer.write(size); >> 80: be_writer.write(time); >> 81: be_writer.write(JfrTicks::now().value() - time); > > Why is this changed? It was a small optimization attempted before the current system of writing virtual thread checkpoints in bulk. Will restore it, thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mgronlun at openjdk.java.net Thu Apr 28 15:11:10 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:11:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:41:04 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp line 94: > >> 92: static const size_t global_buffer_size = 512 * K; >> 93: >> 94: static const size_t thread_local_buffer_prealloc_count = 32; > > Why is more memory needed? Moore's law or something specific to virtual threads? The carrier thread will write the metadata for the mounted virtual threads lazily with virtual threads as part of the event write. They write this thread locally, and the memory increase accommodates fewer roundtrips to fetch new buffers. The previous size was small because it would only hold at most one entry. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mgronlun at openjdk.java.net Thu Apr 28 15:47:16 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 28 Apr 2022 15:47:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 14:44:05 GMT, Erik Gahlin wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp line 168: > >> 166: assert(!tl->is_excluded(), "invariant"); >> 167: if (virtual_thread) { >> 168: // TODO: blob cache for virtual threads > > Fix this now or after integration? Well spotted. It is an optimization and can happen after integration. I will create an enhancement for tracking; thank you. > src/hotspot/share/jfr/metadata/metadata.xml line 121: > >> 119: thread="true" stackTrace="true"> >> 120: >> 121: > > "Continuation class" = >" Continuation Class" > numFrames = frames > numRefs = references > "Number of interpreted frames" => "Interpreted Frames" > "Number of references" => "References" > "Stack size in bytes" => "Stack Size" contentType"bytes" Will fix. > src/hotspot/share/jfr/metadata/metadata.xml line 130: > >> 128: thread="true" stackTrace="true"> >> 129: >> 130: > > contClass => continuationClass > "Continuation class" => "Continuation Class" > "Class of the continuation" Remove (not needed) > "Number of interpreted frames" => "Interpreted Frames" > numFrames => frames > "Number of references" => "References" > numRefs => references > "Stack size in bytes" => "Stack Size" contentType="bytes" Will fix. > src/hotspot/share/jfr/metadata/metadata.xml line 138: > >> 136: >> 137: >> 138: > > "Allocated new" => "Allocated New" Will fix, thanks. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadEndEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread end") > > "Virtual thread end" => "Virtual Thread End" > Remove description. Will fix. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadPinnedEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread pinned") > > "Virtual thread pinned" => "Virtual Thread Pinned" > Remove description Will fix. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadStartEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread start") > > "virtual thread start" => "Virtual Thread Start" > Remove description Will fix, thanks. > src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: > >> 33: >> 34: @Category({"Java Runtime"}) >> 35: @Label("Virtual thread submit task failed") > > The label is a bit a long, would "Virtual Thread Submit Failed" work? It works. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Thu Apr 28 15:47:17 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 15:47:17 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <81ywC27bKQgyP3gndP6y02PPiOfHrTAlU-YA46fZvZ0=.9f0253da-a679-43b9-b445-a598cc193518@github.com> On Thu, 28 Apr 2022 15:10:18 GMT, Markus Gr?nlund wrote: >> src/jdk.jfr/share/classes/jdk/jfr/events/VirtualThreadSubmitFailedEvent.java line 35: >> >>> 33: >>> 34: @Category({"Java Runtime"}) >>> 35: @Label("Virtual thread submit task failed") >> >> The label is a bit a long, would "Virtual Thread Submit Failed" work? > > It works. Thanks. Yes, this is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Thu Apr 28 16:36:39 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 16:36:39 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v4] In-Reply-To: References: Message-ID: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com> On Wed, 27 Apr 2022 05:11:54 GMT, XenoAmess wrote: > Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions. For J2DBench, I don't see any changes that not complicated with older jdk version for now. please recheck. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From darcy at openjdk.java.net Thu Apr 28 16:47:38 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:47:38 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 08:08:37 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java line 55: > >> 53: * against the original path of the directory (irrespective of if the >> 54: * directory is moved since it was opened). >> 55: * @param the type of path > > It may not be a path. The type parameter is specified in the super interfaces, can you copy that down instead? Will change in the next push. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From duke at openjdk.java.net Thu Apr 28 16:56:38 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 16:56:38 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert changes to java.desktop as prrace said ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/684d1528..c9cfb50a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=03-04 Stats: 56 lines in 30 files changed: 8 ins; 0 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From darcy at openjdk.java.net Thu Apr 28 16:58:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:58:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/db4919a9..aaa8f828 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From cjplummer at openjdk.java.net Thu Apr 28 16:58:43 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 28 Apr 2022 16:58:43 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class In-Reply-To: References: <5BL2ETPi-kD_QUBOiwE2HqQUPXfdD9mLttEYWhBfW9Q=.1891a298-2eaf-45e9-8201-2be5dbe9b867@github.com> Message-ID: On Thu, 28 Apr 2022 07:19:34 GMT, David Holmes wrote: >> Lookup.defineHiddenClass allows class options to be specified, one of which is "STRONG" to mean that the hidden class can't unloaded if its defining loader is reachable. >> >> A static reference or a reachability fence should work for this test. > > By default hidden classes are non-strong and can be unloaded when no longer referenced, even if their classloader is still reachable. As you want the hidden class to stick around so it can be reported in the stats then either keep a reference (as you have) or else create it as a STRONG hidden class. I'm ok with the changes but would like to see the comment fixed. It looks like it should be: "Create a hidden non-strong class. Keep a reference in case a GC happens." ------------- PR: https://git.openjdk.java.net/jdk/pull/8438 From darcy at openjdk.java.net Thu Apr 28 16:58:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 16:58:40 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 08:10:38 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/nio/file/WatchEvent.java line 51: > >> 49: /** >> 50: * An event kind, for the purposes of identification. >> 51: * @param the type of the context value > > This is okay but the it differs slightly to the type parameters specified further up. I think the issue here is that it was just wasn't copied down to WatchEvent.Kind. Okay -- I'll for the T type parameter of the Kind interface I'll reuse the wording of the T type parameter of the enclosing WatchEvent interface. (The type variable on Kind could be renamed to show that the two type parameters are distinct.) ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From alanb at openjdk.java.net Thu Apr 28 17:30:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 28 Apr 2022 17:30:50 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From weijun at openjdk.java.net Thu Apr 28 17:43:43 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 28 Apr 2022 17:43:43 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:56:38 GMT, XenoAmess wrote: >> These are the changes that too many to be reviewed in 8186958, thus split some of them out. > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to java.desktop as prrace said src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java line 58: > 56: // start populating content using the specified provider > 57: // common attribute map > 58: HashMap attrs = HashMap.newHashMap(3); Looks like 1 is enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From mchung at openjdk.java.net Thu Apr 28 17:49:48 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Apr 2022 17:49:48 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 18:05:39 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 18:05:39 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: Message-ID: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Update copyright years. - Merge branch 'master' into JDK-8285676 - Respond to more review feedback. - Respond to more review feedback. - Respond to review feedback. - Merge branch 'master' into JDK-8285676 - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8410/files - new: https://git.openjdk.java.net/jdk/pull/8410/files/aaa8f828..cb1fe1c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=03-04 Stats: 687 lines in 59 files changed: 610 ins; 8 del; 69 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410 From darcy at openjdk.java.net Thu Apr 28 18:05:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 28 Apr 2022 18:05:40 GMT Subject: Integrated: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). > > I'll update copyright years before pushing. This pull request has now been integrated. Changeset: bba456a8 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/bba456a8dbf9027e4b015567c17a79fc7441aa08 Stats: 102 lines in 40 files changed: 76 ins; 0 del; 26 mod 8285676: Add missing @param tags for type parameters on classes and interfaces Reviewed-by: wetmore, smarks, dfuchs, prr, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From duke at openjdk.java.net Thu Apr 28 18:07:36 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 18:07:36 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v6] In-Reply-To: References: Message-ID: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. XenoAmess has updated the pull request incrementally with one additional commit since the last revision: change from 3 to 1 according to wangweij ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8301/files - new: https://git.openjdk.java.net/jdk/pull/8301/files/c9cfb50a..1b4bac0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8301&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8301/head:pull/8301 PR: https://git.openjdk.java.net/jdk/pull/8301 From duke at openjdk.java.net Thu Apr 28 18:07:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 28 Apr 2022 18:07:37 GMT Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int) [v5] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:36:41 GMT, Weijun Wang wrote: > Looks like 1 is enough. @wangweij done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8301 From aturbanov at openjdk.java.net Thu Apr 28 18:27:59 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 28 Apr 2022 18:27:59 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> Message-ID: On Thu, 28 Apr 2022 18:05:39 GMT, Joe Darcy wrote: >> To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. >> >> To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. >> >> Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Update copyright years. > - Merge branch 'master' into JDK-8285676 > - Respond to more review feedback. > - Respond to more review feedback. > - Respond to review feedback. > - Merge branch 'master' into JDK-8285676 > - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: > 46: * The {@link #refersTo(Object) refersTo} method can be used to test > 47: * whether some object is the referent of a phantom reference. > 48: * @param the type of the referent Shouldn't there be a space after `@param` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From mchung at openjdk.java.net Thu Apr 28 19:08:52 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 28 Apr 2022 19:08:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> Message-ID: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Update copyright years. >> - Merge branch 'master' into JDK-8285676 >> - Respond to more review feedback. >> - Respond to more review feedback. >> - Respond to review feedback. >> - Merge branch 'master' into JDK-8285676 >> - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces > > src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: > >> 46: * The {@link #refersTo(Object) refersTo} method can be used to test >> 47: * whether some object is the referent of a phantom reference. >> 48: * @param the type of the referent > > Shouldn't there be a space after `@param` ? Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From egahlin at openjdk.java.net Thu Apr 28 19:34:10 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Thu, 28 Apr 2022 19:34:10 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From ayang at openjdk.java.net Thu Apr 28 20:13:34 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 20:13:34 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v5] In-Reply-To: References: Message-ID: <44AueDGOTyuK9Lsclh3_lrRjAnXqCvSCjNf3vYEcN5k=.ceb37603-399b-4852-8512-99079833fe11@github.com> > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8332/files - new: https://git.openjdk.java.net/jdk/pull/8332/files/e4f6a66a..4b9081be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Thu Apr 28 20:13:35 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Apr 2022 20:13:35 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 11:05:45 GMT, Kim Barrett wrote: >> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - comment >> - Rework reference type initialization >> >> Signed-off-by: Albert Yang > > src/hotspot/share/classfile/classFileParser.cpp line 6098: > >> 6096: >> 6097: return _super_klass->reference_type() != REF_NONE; >> 6098: } > > Stylistically, I'd prefer an if-ladder here. I might also swap the reference-type check and the name check, so the for-bootstrapping name check case being last (with a comment to that effect). These if-checks more or less mirror the type hierarchy, `Object -> Reference -> Soft|Weak... -> ...`. Then, walking down the type hierarchy using the early-return style here makes more sense to me. > src/hotspot/share/oops/instanceKlass.cpp line 497: > >> 495: _nest_host_index(0), >> 496: _init_state(allocated), >> 497: _reference_type(REF_NONE), > > This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From lmesnik at openjdk.java.net Thu Apr 28 21:58:46 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 28 Apr 2022 21:58:46 GMT Subject: RFR: 8278123: serviceability/dcmd/vm/ClassLoaderStatsTest.java failing with java.lang.AssertionError: Should have a hidden class [v2] In-Reply-To: References: Message-ID: > The test failed if GC happens somewhere between > Class c = Class.forName("TestClass", true, dummyloader); > and > OutputAnalyzer output = executor.execute("VM.classloader_stats"); > > The fix is to make hc static as Chris proposed. > > To verfiy fix I add System.gc() before executor.execute("VM.classloader_stats"); Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - comment fixed - Merge branch 'master' of https://github.com/openjdk/jdk into 8278123 - fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8438/files - new: https://git.openjdk.java.net/jdk/pull/8438/files/108363b1..1e9d05a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8438&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8438&range=00-01 Stats: 22 lines in 2 files changed: 8 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8438.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8438/head:pull/8438 PR: https://git.openjdk.java.net/jdk/pull/8438 From amenkov at openjdk.java.net Thu Apr 28 23:31:53 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 28 Apr 2022 23:31:53 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From gli at openjdk.java.net Fri Apr 29 00:48:08 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 29 Apr 2022 00:48:08 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Remind: please use the command `/jep JEP-425` [1] to mark this PR. [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Fri Apr 29 03:18:50 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Apr 2022 03:18:50 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: <86rU3tjNaCGgBvhnNs031I3eVZudoZVDhKrnTXvOD7E=.be14c174-df3c-4677-8124-1549069a1bf4@github.com> On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. How does this relate the failure in JDK-8285647? Is this just meant to detect that failure, but a proper fix is still needed for it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From duke at openjdk.java.net Fri Apr 29 03:19:05 2022 From: duke at openjdk.java.net (Will) Date: Fri, 29 Apr 2022 03:19:05 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e Marked as reviewed by will-molloy at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 05:52:00 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 05:52:00 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66: > 64: for (i = 0; i < METH_NUM; i++) > 65: bpEvents[i] = 0; > 66: } As I understand all new tests are C++ based. So, I'd suggest to always use C++ style of loops: for (int i = 0; i < METH_NUM; i++) ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:17:16 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:17:16 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139: > 137: thr_info.name, (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel", > 138: (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user"); > 139: } I'd suggest to add locals (their names are up to you): const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel"; const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user"; It is better to place togeter lines: 129+130. Line 137 is not aligned, and there are many unneeded spaces. The '()' around conditions are not needed. At least, I do not see them increasing readability. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 167: > 165: result = checkStatus = STATUS_FAILED; > 166: LOG( > 167: "TEST FAILED: Breakpoint event with unexpected class signature:\n" Combine lines 166+167. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 187: > 185: jboolean isVirtual = jni->IsVirtualThread(thread); > 186: if (isVirtual != METHODS_ATTRS[i]) { > 187: LOG("TEST FAILED: IsVirtualThread check failed with unexpected result %d when expected is %d\n", isVirtual, METHODS_ATTRS[i]); Line 187 is too long and can be splitted. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 231: > 229: result = STATUS_FAILED; > 230: LOG( > 231: "TEST FAILED: wrong number of Breakpoint events\n" Combine 230+231. test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 307: > 305: if (agent_lock == NULL) { > 306: return JNI_ERR; > 307: } Better to also use same style with curly brackets in fragments: 293, 296, 299. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:23:14 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:23:14 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 139: > 137: primClsEvents[i]++; > 138: LOG( > 139: "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received for\n" Combine 138+138. I won't comment this more in hope the same will be fixed in all tests. test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp line 177: > 175: return JNI_VERSION_1_8; > 176: } > 177: #endif One empty line would be nice to add after 177. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:39:57 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:39:57 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59: > 57: static jvmtiEventCallbacks callbacks; > 58: static jint result = PASSED; > 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO??? I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters. You can remove this comment then. test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 201: > 199: LOG("\n"); > 200: > 201: Too many empty lines. It might make sense to do a common cleanup with all edits like this. test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 258: > 256: return JNI_VERSION_1_8; > 257: } > 258: #endif Empty line is missed => common cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:46:46 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:46:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 178: > 176: ex.c_cls, ex.c_name, ex.c_sig, > 177: (jint)(ex.c_loc >> 32), (jint)ex.c_loc); > 178: result = STATUS_FAILED; Unaligned lines in the range: 172-177. There are some non-uinified unneeded spaces at lines 172,175. test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287: > 285: } > 286: > 287: eventsCount = 0; Counters are not protected with locks. I'm not sure it is a real problem here but would be better to double-check. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From sspitsyn at openjdk.java.net Fri Apr 29 06:50:40 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 29 Apr 2022 06:50:40 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I'm sorry for the noise with my comments. I'll continue to discuss it privately unless there is something really important. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kevinw at openjdk.java.net Fri Apr 29 08:41:43 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 29 Apr 2022 08:41:43 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: <86rU3tjNaCGgBvhnNs031I3eVZudoZVDhKrnTXvOD7E=.be14c174-df3c-4677-8124-1549069a1bf4@github.com> References: <86rU3tjNaCGgBvhnNs031I3eVZudoZVDhKrnTXvOD7E=.be14c174-df3c-4677-8124-1549069a1bf4@github.com> Message-ID: <8q5_Y1ZuYi7Yb_PaVqb1wqz8PPA0WoDWyADCmqLnbJY=.105b07e2-66ef-458f-8a95-4795f64dbf7d@github.com> On Fri, 29 Apr 2022 03:15:09 GMT, Chris Plummer wrote: > How does this relate the failure in JDK-8285647? Is this just meant to detect that failure, but a proper fix is still needed for it? ..it's not directly related - I had this test addition in progress already, as an addition to JDK-8283337 which fixes the modification handler being broken by a previous change (the warning was firing all the time, after JDK-8279124 and before JDK-8283337). So we should have a sanity check (this PR) which fails if the warning starts firing unnecessarily. Logged JDK-8285792 to signal that we need some more cleanup here, including the news that I think JDK-8285647 shows that we don't consistently ignore the crash_handler. ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From prappo at openjdk.java.net Fri Apr 29 08:48:52 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 29 Apr 2022 08:48:52 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> Message-ID: On Thu, 28 Apr 2022 19:06:04 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 48: >> >>> 46: * The {@link #refersTo(Object) refersTo} method can be used to test >>> 47: * whether some object is the referent of a phantom reference. >>> 48: * @param the type of the referent >> >> Shouldn't there be a space after `@param` ? > > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. > Shouldn't there be a space after `@param` ? > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. I built the API documentation after this PR has been integrated and the result was okay. I saw this output in every such case: Type Parameters: T - the type of the referent javadoc is quite robust. However, for some IDEs such missing whitespace seems significant. Not only do they highlight the `@param` tag, but the type parameter information is missing from the rendered output. Although it's not critical, we should fix it; I have filed JDK-8285890. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From prappo at openjdk.java.net Fri Apr 29 09:09:50 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 29 Apr 2022 09:09:50 GMT Subject: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces [v5] In-Reply-To: References: <6vk2LFoiOweHKGiEQxkUjpj9opax4Tj2W0twvjt_BKY=.12784626-14d8-4f2a-9df7-7b7c2c843e6b@github.com> <-4fsP7Oz2b5SHJR3uPUb7dPXo8cVPj0lXNnCDAKgWGA=.7ab1337e-2e75-4dc9-85d8-fb9734ea598c@github.com> Message-ID: On Fri, 29 Apr 2022 08:45:42 GMT, Pavel Rappo wrote: > Good catch. Sorry I missed it. This occurs in all `java/lang/ref` files. I've created a PR; feel free to review it at your convenience. ------------- PR: https://git.openjdk.java.net/jdk/pull/8410 From duke at openjdk.java.net Fri Apr 29 10:41:45 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Fri, 29 Apr 2022 10:41:45 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 13:18:59 GMT, David Holmes wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Thread::current_or_null_safe() and add comments > > src/hotspot/share/prims/forte.cpp line 571: > >> 569: Thread* raw_thread = Thread::current_or_null_safe(); >> 570: >> 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { > > use `rawThread->as_JavaThread()` not a plain cast. this method does not exist ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From kbarrett at openjdk.java.net Fri Apr 29 11:00:44 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 29 Apr 2022 11:00:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 20:06:47 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 497: >> >>> 495: _nest_host_index(0), >>> 496: _init_state(allocated), >>> 497: _reference_type(REF_NONE), >> >> This is initializing `_reference_type` to the wrong value for a `InstanceRefKlass` object, which then needs to reset it in the derived constructor. Why not get the reference type from the parser? The (currently file-scoped static) determine_reference_type function in instanceRefKlass.cpp doesn't have any dependency on the klass object being constructed, just the parser. > > The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. The `_reference_type` used to be initialized correctly in most cases, but needed fixing up for a few cases during bootstrapping. With this change it is *never* initialized correctly for Reference subtypes and always needs an initialization kludge for them. That's not an improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From ayang at openjdk.java.net Fri Apr 29 11:42:44 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 29 Apr 2022 11:42:44 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 10:56:49 GMT, Kim Barrett wrote: >> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file. > > The `_reference_type` used to be initialized correctly in most cases, but > needed fixing up for a few cases during bootstrapping. With this change it is > *never* initialized correctly for Reference subtypes and always needs an > initialization kludge for them. That's not an improvement. `_reference_type` always gets the correct value after the constructor is run. The member initializer list just follows the convention of having all fields set. One could move this field inside the constructor body to ensure this field is set only once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8332 From mseledtsov at openjdk.java.net Fri Apr 29 18:14:01 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 18:14:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/hotspot/jtreg/runtime/vthread/StackChunkClassLoaderTest.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Please update copyright year. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mseledtsov at openjdk.java.net Fri Apr 29 18:30:25 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 18:30:25 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57: > 55: int classLoaderCount = Integer.parseInt(args[0]); > 56: int classCount = Integer.parseInt(args[1]); > 57: for (int i = 0; i 62: theClass.newInstance(); > 63: TestEvent event = new TestEvent(); > 64: event.theClass = event; Did you mean event.theClass = theClass instead ? test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57: > 55: int classLoaderCount = Integer.parseInt(args[0]); > 56: int classCount = Integer.parseInt(args[1]); > 57: for (int i = 0; i References: Message-ID: On Fri, 29 Apr 2022 18:23:35 GMT, Mikhailo Seledtsov wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/jdk/jdk/jfr/api/consumer/TestManyClasses.java line 57: > >> 55: int classLoaderCount = Integer.parseInt(args[0]); >> 56: int classCount = Integer.parseInt(args[1]); >> 57: for (int i = 0; i > Minor: Style: please insert space between < and classCount Also, should this be i < classLoaderCount ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From cjplummer at openjdk.java.net Fri Apr 29 19:09:35 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Apr 2022 19:09:35 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From kevinw at openjdk.java.net Fri Apr 29 20:18:36 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 29 Apr 2022 20:18:36 GMT Subject: RFR: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. thanks David and Alex and Chris 8-) ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From kevinw at openjdk.java.net Fri Apr 29 20:18:36 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Fri, 29 Apr 2022 20:18:36 GMT Subject: Integrated: 8284331: Add sanity check for signal handler modification warning. In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote: > A sanity check using "jcmd VM.info" to catch the signal handler modification warning: it should never trigger during this test. This pull request has now been integrated. Changeset: 116763cb Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/116763cb5d58a7316b7bada689a0fa34a7250ee7 Stats: 20 lines in 1 file changed: 19 ins; 0 del; 1 mod 8284331: Add sanity check for signal handler modification warning. Reviewed-by: dholmes, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8106 From egahlin at openjdk.java.net Fri Apr 29 21:00:27 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 29 Apr 2022 21:00:27 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com> On Fri, 29 Apr 2022 18:27:27 GMT, Mikhailo Seledtsov wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57: > >> 55: int classLoaderCount = Integer.parseInt(args[0]); >> 56: int classCount = Integer.parseInt(args[1]); >> 57: for (int i = 0; i > Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount. The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not created a lot of classes, similar to TestManyClasses. How is this related to Loom? Could this be a merge gone bad? ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From amenkov at openjdk.java.net Fri Apr 29 21:46:01 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 29 Apr 2022 21:46:01 GMT Subject: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java fails with usage tracker Message-ID: The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads. Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads. The change: - updates the test to count only the calls on the test thread; - adds verbose output. ------------- Commit messages: - Fix the test Changes: https://git.openjdk.java.net/jdk/pull/8475/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8475&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279358 Stats: 54 lines in 2 files changed: 39 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8475/head:pull/8475 PR: https://git.openjdk.java.net/jdk/pull/8475 From cjplummer at openjdk.java.net Fri Apr 29 22:01:31 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Apr 2022 22:01:31 GMT Subject: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov wrote: > The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads. > Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads. > > The change: > - updates the test to count only the calls on the test thread; > - adds verbose output. What about ji01t001? Seems it can suffer from the same issues. I know I see the WARNING message in its output for unexpected intercept calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/8475 From cjplummer at openjdk.java.net Fri Apr 29 22:17:32 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 29 Apr 2022 22:17:32 GMT Subject: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov wrote: > The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads. > Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads. > > The change: > - updates the test to count only the calls on the test thread; > - adds verbose output. Also there is [JDK-8284027](https://bugs.openjdk.java.net/browse/JDK-8284027), which also is a failure related to unexpected threads and fails because isThreadExpected() is not filtering all the proper threads (loom makes this issue worse). It looks like you are trying to make the individual tests smarter rather than fixing isThreadExpected(). I'm not saying this is the wrong approach, but we should apply the approach to all tests that use isThreadExpected() . ------------- PR: https://git.openjdk.java.net/jdk/pull/8475 From amenkov at openjdk.java.net Fri Apr 29 22:17:32 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Fri, 29 Apr 2022 22:17:32 GMT Subject: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:12:28 GMT, Chris Plummer wrote: >> The test counts calls of intercepted JNI functions, but doesn't completely filter out calls from other threads. >> Function isThreadExpected is used only for ExceptionOccurred function and the function checks only some known JFR/Graal threads. >> >> The change: >> - updates the test to count only the calls on the test thread; >> - adds verbose output. > > Also there is [JDK-8284027](https://bugs.openjdk.java.net/browse/JDK-8284027), which also is a failure related to unexpected threads and fails because isThreadExpected() is not filtering all the proper threads (loom makes this issue worse). It looks like you are trying to make the individual tests smarter rather than fixing isThreadExpected(). I'm not saying this is the wrong approach, but we should apply the approach to all tests that use isThreadExpected() . @plummercj ji01t001 checks that the number of the calls >= of the expected. I thought about make the same condition here, but decided that it would be better to verify for equality, but ensure we count the calls from the test thread only ------------- PR: https://git.openjdk.java.net/jdk/pull/8475 From mseledtsov at openjdk.java.net Fri Apr 29 23:21:12 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 23:21:12 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e test/lib/jdk/test/lib/thread/VThreadRunner.java line 61: > 59: /** > 60: * Run a task in a virtual thread and wait for it to terminate. > 61: * If the task completse with an exception then it is thrown by this method. typo: completse --> completes test/lib/jdk/test/lib/thread/VThreadRunner.java line 121: > 119: /** > 120: * Run a task in a virtual thread and wait for it to terminate. > 121: * If the task completse with an exception then it is thrown by this method. completse --> completes ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mseledtsov at openjdk.java.net Fri Apr 29 23:57:02 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Fri, 29 Apr 2022 23:57:02 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e I have reviewed the following portions of this change: test/common, test/gtest, test/hotspot/runtime, test/jdk/jfr, test library Feedback: - see several minor comments inline - under runtime/cds/appcds/test-classes there is an empty "TEST.properties" file; was it added by mistake? With only a few minor comments, I approve of the code reviewed by me provided that my comments will be addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Sat Apr 30 10:57:32 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 30 Apr 2022 10:57:32 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 10:38:42 GMT, Johannes Bechberger wrote: >> src/hotspot/share/prims/forte.cpp line 571: >> >>> 569: Thread* raw_thread = Thread::current_or_null_safe(); >>> 570: >>> 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || ((JavaThread*)raw_thread)->is_exiting()) { >> >> use `rawThread->as_JavaThread()` not a plain cast. > > this method does not exist Sorry I meant: `JavaThread::cast(rawThread)` ------------- PR: https://git.openjdk.java.net/jdk/pull/8446