From thartmann at openjdk.org Mon Jul 3 07:21:12 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 3 Jul 2023 07:21:12 GMT Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit Message-ID: Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly. Thanks, Tobias ------------- Commit messages: - 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit Changes: https://git.openjdk.org/jdk21/pull/91/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=91&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310829 Stats: 176 lines in 6 files changed: 123 ins; 21 del; 32 mod Patch: https://git.openjdk.org/jdk21/pull/91.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/91/head:pull/91 PR: https://git.openjdk.org/jdk21/pull/91 From chagedorn at openjdk.org Mon Jul 3 09:13:08 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 3 Jul 2023 09:13:08 GMT Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly. > > Thanks, > Tobias Looks good. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/91#pullrequestreview-1510737726 From thartmann at openjdk.org Mon Jul 3 10:40:59 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 3 Jul 2023 10:40:59 GMT Subject: [jdk21] RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit In-Reply-To: References: Message-ID: <53DPSGZSvBq_pXpb-yMa-jcIA16QJQPhFa_4CiCop5E=.d489538a-7236-4073-8d84-8dac91f9f89a@github.com> On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly. > > Thanks, > Tobias Thanks, Christian! ------------- PR Comment: https://git.openjdk.org/jdk21/pull/91#issuecomment-1617875850 From thartmann at openjdk.org Mon Jul 3 10:41:00 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 3 Jul 2023 10:41:00 GMT Subject: [jdk21] Integrated: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 07:13:14 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310829](https://bugs.openjdk.java.net/browse/JDK-8310829). Applies cleanly. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 6de4e8f6 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk21/commit/6de4e8f601852f9f4b96974dd210ccaf1f655145 Stats: 176 lines in 6 files changed: 123 ins; 21 del; 32 mod 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit Reviewed-by: chagedorn Backport-of: f6bdccb45caca0f69918a773a9ad9b2ad91b702f ------------- PR: https://git.openjdk.org/jdk21/pull/91 From thartmann at openjdk.org Thu Jul 6 11:36:05 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 6 Jul 2023 11:36:05 GMT Subject: [jdk21] RFR: 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null Message-ID: Backport of [JDK-8310425](https://bugs.openjdk.java.net/browse/JDK-8310425). Applies cleanly. Thanks, Tobias ------------- Commit messages: - 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null Changes: https://git.openjdk.org/jdk21/pull/101/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310425 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk21/pull/101.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/101/head:pull/101 PR: https://git.openjdk.org/jdk21/pull/101 From chagedorn at openjdk.org Thu Jul 6 12:36:54 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 6 Jul 2023 12:36:54 GMT Subject: [jdk21] RFR: 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 11:28:49 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310425](https://bugs.openjdk.java.net/browse/JDK-8310425). Applies cleanly. > > Thanks, > Tobias Looks good. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk21/pull/101#pullrequestreview-1516442177 From thartmann at openjdk.org Thu Jul 6 12:36:55 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 6 Jul 2023 12:36:55 GMT Subject: [jdk21] RFR: 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 11:28:49 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310425](https://bugs.openjdk.java.net/browse/JDK-8310425). Applies cleanly. > > Thanks, > Tobias Thanks, Christian! ------------- PR Comment: https://git.openjdk.org/jdk21/pull/101#issuecomment-1623602886 From thartmann at openjdk.org Thu Jul 6 12:57:54 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 6 Jul 2023 12:57:54 GMT Subject: [jdk21] Integrated: 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 11:28:49 GMT, Tobias Hartmann wrote: > Backport of [JDK-8310425](https://bugs.openjdk.java.net/browse/JDK-8310425). Applies cleanly. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 830279e0 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk21/commit/830279e0540c01e2012c60b724857a7fe4a450b1 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod 8310425: [JVMCI] compiler/runtime/TestConstantDynamic: lookupConstant returned an object of incorrect type: null Reviewed-by: chagedorn Backport-of: 15878360bf22c88a6e4038f05efa6db08d72b309 ------------- PR: https://git.openjdk.org/jdk21/pull/101 From jiangli at openjdk.org Sat Jul 8 00:22:09 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 8 Jul 2023 00:22:09 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking Message-ID: Move StringTable to JavaClassFile namespace. ------------- Commit messages: - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking Changes: https://git.openjdk.org/jdk/pull/14808/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311661 Stats: 59 lines in 21 files changed: 14 ins; 0 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/14808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14808/head:pull/14808 PR: https://git.openjdk.org/jdk/pull/14808 From coleenp at openjdk.org Mon Jul 10 14:05:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 10 Jul 2023 14:05:08 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 00:15:01 GMT, Jiangli Zhou wrote: > Move StringTable to JavaClassFile namespace. This seems fine with me. We don't seem to have a namespace name convention in the style guide (was expecting lower case). But this would be an appropriate name to move SymbolTable to also if need be. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14808#pullrequestreview-1522169606 From jiangli at openjdk.org Mon Jul 10 16:40:06 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 16:40:06 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: > Move StringTable to JavaClassFile namespace. Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8311661 - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14808/files - new: https://git.openjdk.org/jdk/pull/14808/files/cb9a4a22..c31ad972 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=00-01 Stats: 594 lines in 42 files changed: 293 ins; 179 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/14808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14808/head:pull/14808 PR: https://git.openjdk.org/jdk/pull/14808 From jiangli at openjdk.org Mon Jul 10 16:40:08 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 16:40:08 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: <5-v5-ztURBv_BUUG3D3NmJyUk3qOKrO92KlKzzzsiV0=.b73cba5b-632c-4867-b4ed-fe8fb8b636cc@github.com> On Mon, 10 Jul 2023 14:02:14 GMT, Coleen Phillimore wrote: > This seems fine with me. We don't seem to have a namespace name convention in the style guide (was expecting lower case). But this would be an appropriate name to move SymbolTable to also if need be. Thanks for the review, Coleen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629320659 From jvernee at openjdk.org Mon Jul 10 21:25:04 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 10 Jul 2023 21:25:04 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot. For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629746328 From coleenp at openjdk.org Mon Jul 10 22:14:13 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 10 Jul 2023 22:14:13 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking How about the namespace being HotSpotClassfile (StringTable is in the classfile directory) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629799696 From jiangli at openjdk.org Mon Jul 10 22:30:15 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 22:30:15 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 21:19:05 GMT, Jorn Vernee wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8311661 >> - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. >> - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking > > The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This patch seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot. > > For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead? @JornVernee thanks for looking into this. > The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This patch seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot. Changing the application or libraries code is not practical in this case as we don't have the full control of what applications or libraries may be linked with. In some cases, developers may not have access to the actual code or required insights to resolve the linkage failures. Fixing the hotspot code using namespace in this case resolves the issue from the source at once, which makes this as a more principled approach. > > For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead? The linking failure involved with duplicate symbol issue concerns internal linkage vs. global linkage, which is different from symbol exporting, IIUC. When duplicating symbol with global linkages from different compilation units linked together, it causes the linking failure. On the other hand, exporting a symbol putting the symbol in the export table, so the symbol can be dynamically looked up. Please see some detailed discussions in: https://github.com/openjdk/jdk/pull/13451#discussion_r1166157315 https://github.com/openjdk/jdk/pull/13451#discussion_r1166209365 https://github.com/openjdk/jdk/pull/13451#discussion_r1166283513 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629814917 From jiangli at openjdk.org Mon Jul 10 22:33:11 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 22:33:11 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: <-w0TpWxSW9CR-Ooh1tWC4c7pDMtuuzliFxR16KiYycM=.29f921b4-f97e-4154-bb7a-f9b988e7a916@github.com> On Mon, 10 Jul 2023 22:11:26 GMT, Coleen Phillimore wrote: > How about the namespace being HotSpotClassfile (StringTable is in the classfile directory) `HotSpotClassfile` sounds ok. I did some search and `HotSpotClassfile` is not used by anyone. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629817584 From jvernee at openjdk.org Mon Jul 10 22:52:12 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 10 Jul 2023 22:52:12 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: <9IerwETUxPNI933g1f3XRjtyWYn0tx6nZfkGkR8rOu8=.52f4af41-243c-442a-a6d2-08465c8748b6@github.com> On Mon, 10 Jul 2023 22:27:12 GMT, Jiangli Zhou wrote: > Changing the application or libraries code is not practical in this case as we don't have the full control of what applications or libraries may be linked with. In some cases, developers may not have access to the actual code or required insights to resolve the linkage failures. Fixing the hotspot code using namespace in this case resolves the issue from the source at once, which makes this as a more principled approach. I'm not suggesting that the application code should be changed. I'm suggesting that a broader solution should be found that avoids this issue in the future, rather than having to patch hotspot again for the next application that comes along and defines a symbol that conflicts. That's what I mean by "principled". I.e. we should be able to explain how to avoid symbol conflicts when statically linking applications against hotspot. I don't think that telling users that, if they have a symbol conflict: "just file a bug report and we will patch hotspot to use a different symbol" is good enough. For instance, we could put all of hotspot into a `HotSpot` namespace, and then document this name space name and require that applications that want to statically link against hotspot don't use the `HotSpot` name space. That would also avoid having to fix up uses of these symbols inside hotspot itself, since things in the same namespace can refer to each other already, without needing a qualifier. > The linking failure involved with duplicate symbol issue concerns internal linkage vs. global linkage, which is different from symbol exporting, IIUC. When duplicating symbol with global linkages from different compilation units linked together, it causes the linking failure. On the other hand, exporting a symbol putting the symbol in the export table, so the symbol can be dynamically looked up. Please see some detailed discussions in: > > [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166157315) [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166209365) [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166283513) Thanks for the pointers. So it sounds like limiting the symbols 'exported' by a static library is not really possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629833628 From jiangli at openjdk.org Mon Jul 10 23:28:12 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Jul 2023 23:28:12 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: <9IerwETUxPNI933g1f3XRjtyWYn0tx6nZfkGkR8rOu8=.52f4af41-243c-442a-a6d2-08465c8748b6@github.com> References: <9IerwETUxPNI933g1f3XRjtyWYn0tx6nZfkGkR8rOu8=.52f4af41-243c-442a-a6d2-08465c8748b6@github.com> Message-ID: On Mon, 10 Jul 2023 22:49:02 GMT, Jorn Vernee wrote: > I'm not suggesting that the application code should be changed. I'm suggesting that a broader solution should be found that avoids this issue in the future, rather than having to patch hotspot again for the next application that comes along and defines a symbol that conflicts. That's what I mean by "principled". I.e. we should be able to explain how to avoid symbol conflicts when statically linking applications against hotspot. Thanks for the clarification, @JornVernee. > I don't think that telling users that, if they have a symbol conflict: "just file a bug report and we will patch hotspot to use a different symbol" is good enough. Agreed. > > For instance, we could put all of hotspot into a `HotSpot` namespace, and then document this name space name and require that applications that want to statically link against hotspot don't use the `HotSpot` name space. That would also avoid having to fix up uses of these symbols inside hotspot itself, since things in the same namespace can refer to each other already, without needing a qualifier. I think using a hotspot special namespace can be a good general solution for resolving and avoiding any potential duplication symbol issue like this. The good news is that with our prototype and testing on JDK 11, we didn't find many duplicate symbol issues with hotspot code specifically. So far we only observed issues with: - `StringTable::StringTable` - `Thread` - `ProfileData` > Thanks for the pointers. So it sounds like limiting the symbols 'exported' by a static library is not really possible. Right. We've looked into following solutions for linkage failures due to symbol conflicts and each solution may be used in different cases when applicable: - Changing to static function/variable, so the symbol has internal linkage (as suggested by @AlanBateman in earlier code review for symbol issues in JDK library code) - Use namespace - Symbol (function, variable) renaming ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629864824 From jiangli at openjdk.org Tue Jul 11 00:16:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 00:16:20 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: <-w0TpWxSW9CR-Ooh1tWC4c7pDMtuuzliFxR16KiYycM=.29f921b4-f97e-4154-bb7a-f9b988e7a916@github.com> References: <-w0TpWxSW9CR-Ooh1tWC4c7pDMtuuzliFxR16KiYycM=.29f921b4-f97e-4154-bb7a-f9b988e7a916@github.com> Message-ID: On Mon, 10 Jul 2023 22:30:29 GMT, Jiangli Zhou wrote: > > How about the namespace being HotSpotClassfile (StringTable is in the classfile directory) > > `HotSpotClassfile` sounds ok. > > I did some search and `HotSpotClassfile` is not used by anyone. I'll change the namespace from `JavaClassFile` to `HotSpotClassFile` as Coleen suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629902921 From coleenp at openjdk.org Tue Jul 11 00:16:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 11 Jul 2023 00:16:22 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking What solutions do you have to resolve "Thread" and "ProfileData" ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629904499 From jiangli at openjdk.org Tue Jul 11 00:28:54 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 00:28:54 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 00:13:19 GMT, Coleen Phillimore wrote: > What solutions do you have to resolve "Thread" and "ProfileData" ? For the `Thread` symbol issue, we simply #defined the symbol to `HotspotBaseThread` in globalDefinitions.hpp in our prototype on JDK 11, to avoid large delta. It would a large change (in terms of touched files and lines) with namespace change. I'll file a bug for the Thread symbol for discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629914710 From jiangli at openjdk.org Tue Jul 11 00:44:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 00:44:13 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 00:26:24 GMT, Jiangli Zhou wrote: > > What solutions do you have to resolve "Thread" and "ProfileData" ? > > For the `Thread` symbol issue, we simply #defined the symbol to `HotspotBaseThread` in globalDefinitions.hpp in our prototype on JDK 11, to avoid large delta. It would a large change (in terms of touched files and lines) with namespace change. I'll file a bug for the Thread symbol for discussion. https://bugs.openjdk.org/browse/JDK-8311846 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629924519 From coleenp at openjdk.org Tue Jul 11 01:37:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 11 Jul 2023 01:37:27 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking Ok, yeah, I'd hate for Thread to get a namespace:: prepended to the million uses of it. Maybe the same approach should be used for StringTable too, since they're solving the same problem. Is there an #if STATIC_LINK or something that surrounds this #define? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629965664 From iklam at openjdk.org Tue Jul 11 04:26:12 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Jul 2023 04:26:12 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking If there are only 3 problematic symbols, wouldn't it be easier to configure the JDK with bash configure --with-extra-cxxflags='-DStringTable=HotSpotStringTable -DThread=HotSpotThread -DProfileData=HotSpotProfileData' That way, you don't need to submit a new PR every time there's a new conflict. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1630091307 From jiangli at openjdk.org Tue Jul 11 05:08:54 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 05:08:54 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 01:34:13 GMT, Coleen Phillimore wrote: > Ok, yeah, I'd hate for Thread to get a namespace:: prepended to the million uses of it. Maybe the same approach should be used for StringTable too, since they're solving the same problem. `#define` renaming is a good workaround to avoid editing larger number of files and reducing integration/merge issues. Using namespace seems to be a better choice in the JDK mainline. We can also reduce the needed edits with `using`. > Is there an #if STATIC_LINK or something that surrounds this #define? We are proposing removing `#ifdef STATIC_BUILD` in https://github.com/jianglizhou/jdk/tree/static-java (not complete). That allows building `.so` and `.a` from the same set of object files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1630123619 From jiangli at openjdk.org Tue Jul 11 05:13:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 05:13:20 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 04:23:08 GMT, Ioi Lam wrote: > If there are only 3 problematic symbols, wouldn't it be easier to configure the JDK with > > ``` > bash configure --with-extra-cxxflags='-DStringTable=HotSpotStringTable -DThread=HotSpotThread -DProfileData=HotSpotProfileData' > ``` > > That way, you don't need to submit a new PR every time there's a new conflict. Thanks, I haven't explored that option. Seems to be a useful quick fix when experimenting with JDK static linking. As we are working towards a longer term and more general solution, resolving the issues in hotspot code seems to be better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1630130242 From coleenp at openjdk.org Tue Jul 11 15:31:13 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 11 Jul 2023 15:31:13 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking When you add in Thread, the namespace solution seems a lot less attractive unless you can do "using namespace hotspot;" around all the code in the JVM without altering names everywhere. Having sets of different HotSpotX namespaces seems a lot less attractive in the code and isn't really more general. So I don't think this is a good change anymore. Maybe there is a build option to wrap names as Ioi suggested or some global namespace wrapping. But then we'd just want to wrap the whole thing in namespace hotspot. This code was written before namespaces existed everywhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631038577 From coleenp at openjdk.org Tue Jul 11 15:37:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 11 Jul 2023 15:37:06 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking I think I've changed my mind. Since static build is a build time issue, then maybe a source solution shouldn't be done for this. src/hotspot/share/runtime/serviceThread.cpp line 119: > 117: (has_dcmd_notification_event = (!UseNotificationThread && DCmdFactory::has_pending_jmx_notification())) | > 118: (stringtable_work = JavaClassFile::StringTable::has_work()) | > 119: (symboltable_work = SymbolTable::has_work()) | It does look strange since you'd expect SymbolTable to be in the same namespace. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14808#pullrequestreview-1524561569 PR Review Comment: https://git.openjdk.org/jdk/pull/14808#discussion_r1259912370 From stuefe at openjdk.org Tue Jul 11 15:47:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 11 Jul 2023 15:47:04 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking Hi, to prevent clashes like this, libraries that support static linking tend to define a global namespace or a common prefix, usually switchable via defines. IIRC sqlite does this, zlib, jemalloc... If we could pull such a thing off with a minimum of invasiveness, it would be a much more robust solution. If we introduce such a namespace, the name could be very short and non-descriptive, and then be defined (or completely switched off by default) via compile option. That way one could even link two hotspots if one wanted (only one usuable at a time for other reasons). If combined with "using" somewhere, maybe in precompiled.hpp, this solution may not be that invasive. Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631065356 From iklam at openjdk.org Tue Jul 11 16:23:22 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Jul 2023 16:23:22 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 15:44:30 GMT, Thomas Stuefe wrote: > Hi, > > to prevent clashes like this, libraries that support static linking tend to define a global namespace or a common prefix, usually switchable via defines. IIRC sqlite does this, zlib, jemalloc... If we could pull such a thing off with a minimum of invasiveness, it would be a much more robust solution. Do the libraries that you mention just enclose every .cpp and .hpp files with `namespace xxx {` and `}`. Something like // thread.hpp #include <....> #include <....> #include <....> namespace hotspot { // <<< add class Thread {....} } // <<< add That doesn't look too bad to me, as we just need to do this once, and it can (probably) be done with a script. > > If we introduce such a namespace, the name could be very short and non-descriptive, and then be defined (or completely switched off by default) via compile option. That way one could even link two hotspots if one wanted (only one usuable at a time for other reasons). > > If combined with "using" somewhere, maybe in precompiled.hpp, this solution may not be that invasive. Are you suggesting something like this? // precompiled.hpp namespace hotspot {} using Bar = hotspot::Bar; // bar.h, the "Bar" class is automatically put inside "hotspot" namespace. class Bar { static int a() { return 0; } }; I tried it but couldn't get it to work. The `using` must be put after the type of `hotspot::Bar` has already been declared. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631120256 From jvernee at openjdk.org Tue Jul 11 16:43:15 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 11 Jul 2023 16:43:15 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking `using namespace hotspot;` could be used I think: > using namespace ns-name ; | (5) > 5) [using-directive](https://en.cppreference.com/w/cpp/language/namespace#Using-directives): From the point of view of unqualified [name lookup](https://en.cppreference.com/w/cpp/language/lookup) of any name after a using-directive and until the end of the scope in which it appears, every name from ns-name is visible as if it were declared in the nearest enclosing namespace which contains both the using-directive and ns-name. (From: https://en.cppreference.com/w/cpp/language/namespace) But, if we put everything in the same `hotspot` namespace we shouldn't need to add `hotspot::` qualifiers since things in the same namespace can already refer to each other: namespace hotspot { class Bar { public: static int a() { return 0; } }; int func(Bar* bar) { // Bar is unqualified here return bar->a(); } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631147930 From jiangli at openjdk.org Tue Jul 11 16:49:12 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 16:49:12 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 16:19:40 GMT, Ioi Lam wrote: > > Hi, > > to prevent clashes like this, libraries that support static linking tend to define a global namespace or a common prefix, usually switchable via defines. IIRC sqlite does this, zlib, jemalloc... If we could pull such a thing off with a minimum of invasiveness, it would be a much more robust solution. > > Do the libraries that you mention just enclose every .cpp and .hpp files with `namespace xxx {` and `}`. Both zlib and jemalloc achieve name space isolations via #define, although not in C++ namespace definition. I think that's what @tstuefe was referring to. > > Something like > > // thread.hpp > #include <....> > #include <....> > #include <....> > namespace hotspot { // <<< add > class Thread {....} > } // <<< add > That doesn't look too bad to me, as we just need to do this once, and it can (probably) be done with a script. Global namespace (as @JornVernee has suggested) does sound attractive as long as we can do it without very invasive changes. It's also a more future-proof solution. I'll do some exploration as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631156523 From iklam at openjdk.org Tue Jul 11 17:05:56 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Jul 2023 17:05:56 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 16:39:50 GMT, Jorn Vernee wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8311661 >> - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. >> - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking > > `using namespace hotspot;` could be used I think: > >> using namespace ns-name ; | (5) > >> 5) [using-directive](https://en.cppreference.com/w/cpp/language/namespace#Using-directives): From the point of view of unqualified [name lookup](https://en.cppreference.com/w/cpp/language/lookup) of any name after a using-directive and until the end of the scope in which it appears, every name from ns-name is visible as if it were declared in the nearest enclosing namespace which contains both the using-directive and ns-name. > > (From: https://en.cppreference.com/w/cpp/language/namespace) > > But, if we put everything in the same `hotspot` namespace we shouldn't need to add `hotspot::` qualifiers since things in the same namespace can already refer to each other: > > > namespace hotspot { > class Bar { > public: > static int a() { return 0; } > }; > > int func(Bar* bar) { // Bar is unqualified here > return bar->a(); > } > } > Global namespace (as @JornVernee has suggested) does sound attractive as long as we can do it without very invasive changes. It's also a more future-proof solution. I'll do some exploration as well. Something like this might work. We need to enclose all declarations inside `namespace hotspot {...}`, so all .hpp files need to be touched (which I think is OK). We can add the `using namespace hotspot` in precompiled.hpp so we that can avoid modifying most .cpp files. `using namespace` affects only the lookup of existing names. It doesn't affect the declaration of new types (like Bar in my example below). // precompiled.hpp namespace hotspot {} using namespace hotspot; // foo.hpp namespace hotspot { class Foo { public: static int x(); }; } // bar.hpp class Bar { // declares ::Bar, not hotspot::Bar public: static int a() { return 2; } }; // foo.cpp int Foo::x() { return 1; } // defines Hotspot::Foo::x() int main() { printf("%d %d\n", Foo::x(), hotspot::Foo::x()); //printf("%d %d\n", Bar::a(), hotspot::Bar::x()); <-- this doesn't work } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631178570 From dlong at openjdk.org Tue Jul 11 19:57:09 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 11 Jul 2023 19:57:09 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking I think we already used -fvisibility=hidden to solve problems like this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631426872 From jiangli at openjdk.org Tue Jul 11 20:21:06 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 20:21:06 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 19:53:58 GMT, Dean Long wrote: > I think we already used -fvisibility=hidden to solve problems like this. Right, the `stringTable.o` was already compiled with `-fvisibility=hidden` for example. `-fvisibility=hidden` didn't resolve the duplicate symbol issue with static linking. We ran into the duplicate duplicate symbol linking failure when user code also defines the symbol and statically linked together with hotspot `libjvm.a`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631455504 From dlong at openjdk.org Tue Jul 11 20:38:13 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 11 Jul 2023 20:38:13 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking Does passing -Wl,--exclude-libs,ALL to gcc work for static libs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631474057 From jiangli at openjdk.org Tue Jul 11 20:44:15 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 20:44:15 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 17:03:12 GMT, Ioi Lam wrote: > Something like this might work. We need to enclose all declarations inside `namespace hotspot {...}`, so all .hpp files need to be touched (which I think is OK). I just looked briefly. For `.hpp` files alone in `hotspot` dir, we have 2276. Although the number of files is large, I think the actual changes are trivial. Still want to make sure everyone is okay with the changes at this scale. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631481093 From iklam at openjdk.org Tue Jul 11 21:11:14 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Jul 2023 21:11:14 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: <5cl-bjjTvbpCd2yM0xRcarMllvDMqyapqD2ec2_Z_mc=.205b5d59-6bd5-4978-873b-49f32bf458a3@github.com> On Tue, 11 Jul 2023 20:41:16 GMT, Jiangli Zhou wrote: > > Something like this might work. We need to enclose all declarations inside `namespace hotspot {...}`, so all .hpp files need to be touched (which I think is OK). > > I just looked briefly. For `.hpp` files alone in `hotspot` dir, we have 2276. Although the number of files is large, I think the actual changes are trivial. Still want to make sure everyone is okay with the changes at this scale. If adding `using hotspot` in precompiled.hpp works, we can roll this out in stages. At the beginning, we can just put the three problematic classes (`Thread`, `StringTable` and `ProfileData`) in the `hotspot` namespace, so only a few files need to be changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631511102 From jiangli at openjdk.org Tue Jul 11 22:26:10 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 22:26:10 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 20:35:13 GMT, Dean Long wrote: > Does passing -Wl,--exclude-libs,ALL to gcc work for static libs? I just did a quick test using `gcc` with testing code added to define `StringTable` related symbols outside `libjvm.a`. With `-Wl,--exclude-libs,ALL`, statically linking the launcher executable with `libjvm.a` and the testing code fails due to multiple definition of the related symbols. I guess that's expected as `--exclude-libs` is for controlling symbol exporting. >From https://linux.die.net/man/1/ld#:~:text=Specifying%20%22%2D%2Dexclude%2Dlibs%20ALL,and%20for%20ELF%20targeted%20ports. --exclude-libs lib,lib,... Specifies a list of archive libraries from which symbols should not be automatically exported. The library names may be delimited by commas or colons. Specifying "--exclude-libs ALL" excludes symbols in all archive libraries from automatic export. This option is available only for the i386 PE targeted port of the linker and for ELF targeted ports. For i386 PE , symbols explicitly listed in a .def file are still exported, regardless of this option. For ELF targeted ports, symbols affected by this option will be treated as hidden. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631585756 From iklam at openjdk.org Tue Jul 11 22:41:06 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Jul 2023 22:41:06 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou wrote: >> Move StringTable to JavaClassFile namespace. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8311661 > - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. > - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking I found a way to hide the unwanted symbols in libjvm.a. This requires `ld --relocatable` and `objcopy --keep-global-symbols=...`. See the prototype here: - https://github.com/iklam/tools/tree/main/misc/staticlib So potentially we can do this completely in the makefiles, without adding namespaces to HotSpot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631597197 From jiangli at openjdk.org Tue Jul 11 23:00:14 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Jul 2023 23:00:14 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: References: Message-ID: On Tue, 11 Jul 2023 22:38:10 GMT, Ioi Lam wrote: > I found a way to hide the unwanted symbols in libjvm.a. This requires `ld --relocatable` and `objcopy --keep-global-symbols=...`. See the prototype here: > > * https://github.com/iklam/tools/tree/main/misc/staticlib > > So potentially we can do this completely in the makefiles, without adding namespaces to HotSpot. Yeah, `objcopy` can be used to localize symbols. One of my colleague implemented symbol localizing for `libfreetype.a` and `libharfbuzz.a` for static linking issue. In some cases, user might want to link with a different version of the harfbuzz library than the version linked with the JDK code. Then multiple versions of the libraries could be linked together into the executable. That was a solution suggested by C++ experts and it worked. Doing partial linking that produces a single `.o` file simplifies the work of `objcopy`. This is not a very portable solution though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631611220 From jiangli at openjdk.org Wed Jul 12 01:29:24 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Jul 2023 01:29:24 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: <5cl-bjjTvbpCd2yM0xRcarMllvDMqyapqD2ec2_Z_mc=.205b5d59-6bd5-4978-873b-49f32bf458a3@github.com> References: <5cl-bjjTvbpCd2yM0xRcarMllvDMqyapqD2ec2_Z_mc=.205b5d59-6bd5-4978-873b-49f32bf458a3@github.com> Message-ID: <0J49MlUO8xVYipLytP2Fzd9KNWZfd0J3fge92B0Mq3g=.388bfe76-2854-466b-a64c-3a93d00b168a@github.com> On Tue, 11 Jul 2023 21:08:01 GMT, Ioi Lam wrote: > > > Something like this might work. We need to enclose all declarations inside `namespace hotspot {...}`, so all .hpp files need to be touched (which I think is OK). > > > > > > I just looked briefly. For `.hpp` files alone in `hotspot` dir, we have 2276. Although the number of files is large, I think the actual changes are trivial. Still want to make sure everyone is okay with the changes at this scale. > > If adding `using hotspot` in precompiled.hpp works, we can roll this out in stages. At the beginning, we can just put the three problematic classes (`Thread`, `StringTable` and `ProfileData`) in the `hotspot` namespace, so only a few files need to be changed. Moving to the namespace incrementally seems to be reasonable to me. Will let others to chime in on this for their thoughts. Add `using ` to precompiled.hpp does help avoid adding `::` in many places. We still need to put the implementation code inside `namespace { ...}`, or use `::`. I experimented with StringTable and only needed to edit stringTable.* and precompiled.hpp. I tested with and without `--disable-precompiled-headers` and both built ok. C++ references that I read discourages using `using` directive. https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice has some helpful information. For the namespace usages within hotspot, there is probably no concern with pollution. It seems eventually all code would be moved to the namespace then `using` would not be needed. `Thread` change would be bigger. There are references like `class Thread;`. It seems to be a good idea to be handled with https://bugs.openjdk.org/browse/JDK-8311846 separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1631715225 From jiangli at openjdk.org Wed Jul 12 16:54:28 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Jul 2023 16:54:28 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v3] In-Reply-To: References: Message-ID: > Move StringTable to JavaClassFile namespace. Jiangli Zhou 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: - Merge branch 'master' into JDK-8311661 - - Change to use a hotspot global namespace, based on the discussions in this PR thread. The namespace is 'hotspot_jvm', which may have less chance of collisions than 'hotspot'. - Use 'using' directive in precompiled.hpp, as suggested by others in the PR comments. - Merge branch 'master' into JDK-8311661 - Move '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'. - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14808/files - new: https://git.openjdk.org/jdk/pull/14808/files/c31ad972..3385b743 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=01-02 Stats: 1783 lines in 118 files changed: 1218 ins; 333 del; 232 mod Patch: https://git.openjdk.org/jdk/pull/14808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14808/head:pull/14808 PR: https://git.openjdk.org/jdk/pull/14808 From jiangli at openjdk.org Wed Jul 12 19:29:31 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Jul 2023 19:29:31 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: References: Message-ID: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> > Move StringTable to JavaClassFile namespace. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add hotspot_jvm:: to StringTable in javaClasses.hpp. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14808/files - new: https://git.openjdk.org/jdk/pull/14808/files/3385b743..db681ecf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14808&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14808/head:pull/14808 PR: https://git.openjdk.org/jdk/pull/14808 From jiangli at openjdk.org Wed Jul 12 23:10:56 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Jul 2023 23:10:56 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: <0J49MlUO8xVYipLytP2Fzd9KNWZfd0J3fge92B0Mq3g=.388bfe76-2854-466b-a64c-3a93d00b168a@github.com> References: <5cl-bjjTvbpCd2yM0xRcarMllvDMqyapqD2ec2_Z_mc=.205b5d59-6bd5-4978-873b-49f32bf458a3@github.com> <0J49MlUO8xVYipLytP2Fzd9KNWZfd0J3fge92B0Mq3g=.388bfe76-2854-466b-a64c-3a93d00b168a@github.com> Message-ID: On Wed, 12 Jul 2023 01:26:08 GMT, Jiangli Zhou wrote: > Add `using ` to precompiled.hpp does help avoid adding `::` in many places. We still need to put the implementation code inside `namespace { ...}`, or use `::`. I experimented with StringTable and only needed to edit stringTable.* and precompiled.hpp. I tested with and without `--disable-precompiled-headers` and both built ok. src/hotspot/share/classfile/javaClasses.hpp also needs change, otherwise it fails to build on windows. I updated the PR with suggestions incorporated. Please take a look of the updated version, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1633318213 From iklam at openjdk.org Thu Jul 13 18:05:10 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 13 Jul 2023 18:05:10 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> References: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> Message-ID: <7RYF5SEdxG-CBlpMo4Ts1ZznVZPTdU9VHmhalQvKW-Q=.0d515dc8-666a-49a5-9098-2caeeaaf8d79@github.com> On Wed, 12 Jul 2023 19:29:31 GMT, Jiangli Zhou wrote: >> Move StringTable to 'hotspot_jvm' namespace. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Add hotspot_jvm:: to StringTable in javaClasses.hpp. Hi Jiangli, Putting the HotSpot code in a namespace is a fundamental change that should be done in a JEP. The idea of using namespaces for HotSpot has been around for a while, but so far there hasn't been a strong motivation for doing it. Perhaps static linking would finally give us a go-ahead reason. The JEP should discuss the goals, design choices, risks and alternatives. For example: - Other than static linking, what other problems can we solve with namespaces? Knowing the other goals may help us in choosing a design. - Do we want a single namespace, or multiple namespaces (one for GC, one for JIT, etc) - Do we want to change over incrementally (as in this PR), or in a single step - Do we want to enable namespaces optionally (e.g., only for static linking)? - With namespaces, the debug symbols will be much bigger, and we could also run into issues with debuggers and other tools. - There may be alternatives for static linking that may have less impact than namespaces. The [hotspot-dev mailing list](https://mail.openjdk.org/mailman/listinfo/hotspot-dev) would be the best place to have such discussions. Also, at this time, many OpenJDK developers who are interested on this topic are on vacation, so we probably need to wait till the end of the summer so everyone has a chance to chime in. JEP may feel like a lot of process, but for this change, I think it's the best avenue for exploration. Thanks Ioi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1634674049 From stuefe at openjdk.org Thu Jul 13 18:43:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 13 Jul 2023 18:43:14 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2] In-Reply-To: <0J49MlUO8xVYipLytP2Fzd9KNWZfd0J3fge92B0Mq3g=.388bfe76-2854-466b-a64c-3a93d00b168a@github.com> References: <5cl-bjjTvbpCd2yM0xRcarMllvDMqyapqD2ec2_Z_mc=.205b5d59-6bd5-4978-873b-49f32bf458a3@github.com> <0J49MlUO8xVYipLytP2Fzd9KNWZfd0J3fge92B0Mq3g=.388bfe76-2854-466b-a64c-3a93d00b168a@github.com> Message-ID: On Wed, 12 Jul 2023 01:26:08 GMT, Jiangli Zhou wrote: > Moving to the namespace incrementally seems to be reasonable to me. Will let others to chime in on this for their thoughts. I also like the incremental namespace solution. @iklam wrote: > > The [hotspot-dev mailing list](https://mail.openjdk.org/mailman/listinfo/hotspot-dev) would be the best place to have such discussions. Also, at this time, many OpenJDK developers who are interested on this topic are on vacation, so we probably need to wait till the end of the summer so everyone has a chance to chime in. > > JEP may feel like a lot of process, but for this change, I think it's the best avenue for exploration. > I agree with @iklam that we should discuss this on hotspot-dev. It will affect the whole JDK and constitute a change that is visible from outside, so we should get this right. I also think that making the hotspot linkable in a static way could be very useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1634720487 From jiangli at openjdk.org Thu Jul 13 18:53:08 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 13 Jul 2023 18:53:08 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: <7RYF5SEdxG-CBlpMo4Ts1ZznVZPTdU9VHmhalQvKW-Q=.0d515dc8-666a-49a5-9098-2caeeaaf8d79@github.com> References: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> <7RYF5SEdxG-CBlpMo4Ts1ZznVZPTdU9VHmhalQvKW-Q=.0d515dc8-666a-49a5-9098-2caeeaaf8d79@github.com> Message-ID: On Thu, 13 Jul 2023 18:01:47 GMT, Ioi Lam wrote: > Hi Jiangli, > > Putting the HotSpot code in a namespace is a fundamental change that should be done in a JEP. The idea of using namespaces for HotSpot has been around for a while, but so far there hasn't been a strong motivation for doing it. Perhaps static linking would finally give us a go-ahead reason. > > The JEP should discuss the goals, design choices, risks and alternatives. For example: > > * Other than static linking, what other problems can we solve with namespaces? Knowing the other goals may help us in choosing a design. > * Do we want a single namespace, or multiple namespaces (one for GC, one for JIT, etc) > * Do we want to change over incrementally (as in this PR), or in a single step > * Do we want to enable namespaces optionally (e.g., only for static linking)? > * With namespaces, the debug symbols will be much bigger, and we could also run into issues with debuggers and other tools. > * There may be alternatives for static linking that may have less impact than namespaces. > > The [hotspot-dev mailing list](https://mail.openjdk.org/mailman/listinfo/hotspot-dev) would be the best place to have such discussions. Also, at this time, many OpenJDK developers who are interested on this topic are on vacation, so we probably need to wait till the end of the summer so everyone has a chance to chime in. > > JEP may feel like a lot of process, but for this change, I think it's the best avenue for exploration. > > Thanks Ioi Thanks for the response, @iklam. Going through the JEP for the hotspot namespace makes a lot of sense. Waiting until the end of summer also sounds good to me. Maybe it's still early to ask the question, would you be willing to drive the JEP for the namespace changes? I'm happy to write up the JEP otherwise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1634731589 From iklam at openjdk.org Thu Jul 13 19:47:05 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 13 Jul 2023 19:47:05 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: References: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> <7RYF5SEdxG-CBlpMo4Ts1ZznVZPTdU9VHmhalQvKW-Q=.0d515dc8-666a-49a5-9098-2caeeaaf8d79@github.com> Message-ID: On Thu, 13 Jul 2023 18:49:47 GMT, Jiangli Zhou wrote: > Maybe it's still early to ask the question, would you be willing to drive the JEP for the namespace changes? I'm happy to write up the JEP otherwise. I'll be happy to facilitate the discussion for this topic, but I am really not an expert on C++ namespaces. Also, I think such a JEP should be led by someone who has an interest of putting HotSpot in namespaces. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1634811516 From dholmes at openjdk.org Fri Jul 14 02:50:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Jul 2023 02:50:15 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> References: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> Message-ID: On Wed, 12 Jul 2023 19:29:31 GMT, Jiangli Zhou wrote: >> Move StringTable to 'hotspot_jvm' namespace. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Add hotspot_jvm:: to StringTable in javaClasses.hpp. I am concerned that something that [JDK-8303796](https://bugs.openjdk.org/browse/JDK-8303796) claimed to be a small enhancement is in fact requiring a lot of changes in different areas of the codebase. There are already a number of "duplicate symbol definition" issues that have been filed and fixed in an ad-hoc manner in the JDK, which is the kind of whack-a-mole approach that we should not be taking. If static linking requires symbol isolation then a generally applicable approach to doing that should be investigated (in a separate project? Leyden?) and then brought to mainline via a JEP (not just for the hotspot aspect as currently suggested). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1635186576 From jiangli at openjdk.org Mon Jul 17 18:06:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 17 Jul 2023 18:06:17 GMT Subject: RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4] In-Reply-To: References: <3mXE9RE6cj-apUgKbUvy0yxneWeSXHmMURj0JMhZKxw=.0a532743-5258-47c2-84bf-590f0a2660cc@github.com> Message-ID: On Fri, 14 Jul 2023 02:46:47 GMT, David Holmes wrote: > I am concerned that something that [JDK-8303796](https://bugs.openjdk.org/browse/JDK-8303796) claimed to be a small enhancement is in fact requiring a lot of changes in different areas of the codebase. @dholmes-ora, sorry for the slow response, I was OOO. The fixes and enhancements for JDK-8303796 include: - duplicate symbol fixes - Make file changes to create the full set of static libraries - Runtime fixes open sourced at https://github.com/jianglizhou/jdk/tree/static-java - Fix runtime crashes - Enhance builtin libraries lookup - Use runtime checks to detect JDK static build. Allow removing STATIC_BUILD macro and building static and dynamic libraries without rebuild .o files The overall changes are not small. Individually each fix or enhancement, poetically the symbol fix is relatively small and non-complicated (except the built-in libraries lookup changes). Handling them as separate bugs and enhancements seems to be reasonable. The built-in library lookup and runtime changes may be suitable for a new JEP or putting in a Leyden project repo and propose later. It's built on top of the existing JEP 178: Statically-Linked JNI Libraries. To me, handling it with a new JEP as an enhancement on top of JEP 178 is reasonable. Any thoughts on that? > There are already a number of "duplicate symbol definition" issues that have been filed and fixed in an ad-hoc manner in the JDK, which is the kind of whack-a-mole approach that we should not be taking. If static linking requires symbol isolation then a generally applicable approach to doing that should be investigated (in a separate project? Leyden?) and then brought to mainline via a JEP (not just for the hotspot aspect as currently suggested). The duplicated symbol issues consist three parts: 1. Symbol conflicts among the JDK native libraries and hotspot Each issue is different and has been fixed in an ad-hoc manner. All issues have fixed by bugs linked with JDK-8303796. With enabling static JDK build (not yet done currently), we will be able to detect and prevent introducing new symbol issues in the future. 2. Symbol conflicts between hotspot and user code This is discussed by the thread in this PR. Moving hotspot code to hotspot unique namespace as suggested by @JornVernee is a good general solution. 3. Symbol conflicts between JDK library and user code With our prototype we found about 5 of those. I think these are outliers. Either fixing them as individually bugs or putting them in a Leyden repo and proposing together seems ok. Since the number is small enough, fixing individually might be slightly cleaner. Please let me know your thoughts. The JNI code defines APIs with naming convention consisting Java package and class names. There is no symbol issue with those. To prevent future issues, following the same naming style for helper methods and variables in JDK native code would work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1638622132 From dnsimon at openjdk.org Wed Jul 19 13:49:54 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 19 Jul 2023 13:49:54 GMT Subject: RFR: 8312235: [JVMCI] need version of ConstantPool.lookupConstant without eager resolution Message-ID: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: /** * Looks up a constant at the specified index. * * If {@code resolve == false} and the denoted constant is of type * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then * {@code null} is returned. * * @param cpi the constant pool index * @return the {@code Constant} or {@code JavaType} instance representing the constant pool * entry */ Object lookupConstant(int cpi, boolean resolve); --------- ### Progress - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue ### Reviewing
Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ `$ git checkout pull/14927` Update a local copy of the PR: \ `$ git checkout pull/14927` \ `$ git pull https://git.openjdk.org/jdk.git pull/14927/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 14927` View PR using the GUI difftool: \ `$ git pr show -t 14927`
Using diff file Download this PR as a diff file: \ https://git.openjdk.org/jdk/pull/14927.diff
------------- Commit messages: - update TestDynamicConstant to test new ConstantPool.lookupConstant method - add ConstantPool.lookupConstant(int cpi, boolean resolve) Changes: https://git.openjdk.org/jdk/pull/14927/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312235 Stats: 358 lines in 8 files changed: 195 ins; 152 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927 PR: https://git.openjdk.org/jdk/pull/14927 From dnsimon at openjdk.org Thu Jul 20 18:05:07 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 20 Jul 2023 18:05:07 GMT Subject: RFR: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> > The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: > > > /** > * Looks up a constant at the specified index. > * > * If {@code resolve == false} and the denoted constant is of type > * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or > * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then > * {@code null} is returned. > * > * @param cpi the constant pool index > * @return the {@code Constant} or {@code JavaType} instance representing the constant pool > * entry > */ > Object lookupConstant(int cpi, boolean resolve); > > > Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ > `$ git checkout pull/14927` > > Update a local copy of the PR: \ > `$ git checkout pull/14927` \ > `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 14927` > > View PR using the GUI difftool: \ > `$ git pr show -t 14927` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/14927.diff > >
Doug Simon has updated the pull request incrementally with one additional commit since the last revision: avoid bootstrap method invocation by lookupBootstrapMethodInfo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14927/files - new: https://git.openjdk.org/jdk/pull/14927/files/54c54047..4621c13a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=00-01 Stats: 126 lines in 5 files changed: 76 ins; 19 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/14927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927 PR: https://git.openjdk.org/jdk/pull/14927 From dnsimon at openjdk.org Thu Jul 20 18:17:45 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 20 Jul 2023 18:17:45 GMT Subject: RFR: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: On Thu, 20 Jul 2023 18:08:16 GMT, Tom Rodriguez wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid bootstrap method invocation by lookupBootstrapMethodInfo > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 666: > >> 664: * entries do not have a symbol in the constant pool slot. >> 665: */ >> 666: return compilerToVM().lookupConstantInPool(this, cpi, true); > > This is true because it's always safe to do so? I don't really know what these "pseudo strings" are. In any case, I don't think resolving them involves calling any Java code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1269807593 From never at openjdk.org Thu Jul 20 18:17:43 2023 From: never at openjdk.org (Tom Rodriguez) Date: Thu, 20 Jul 2023 18:17:43 GMT Subject: RFR: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: On Thu, 20 Jul 2023 18:05:07 GMT, Doug Simon wrote: >> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: >> >> >> /** >> * Looks up a constant at the specified index. >> * >> * If {@code resolve == false} and the denoted constant is of type >> * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or >> * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then >> * {@code null} is returned. >> * >> * @param cpi the constant pool index >> * @return the {@code Constant} or {@code JavaType} instance representing the constant pool >> * entry >> */ >> Object lookupConstant(int cpi, boolean resolve); >> >> >> Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. >> >> --------- >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ >> `$ git checkout pull/14927` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/14927` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 14927` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 14927` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/14927.diff >> >>
> > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > avoid bootstrap method invocation by lookupBootstrapMethodInfo Marked as reviewed by never (Reviewer). src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 666: > 664: * entries do not have a symbol in the constant pool slot. > 665: */ > 666: return compilerToVM().lookupConstantInPool(this, cpi, true); This is true because it's always safe to do so? ------------- PR Review: https://git.openjdk.org/jdk/pull/14927#pullrequestreview-1539822479 PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1269804156 From never at openjdk.org Thu Jul 20 18:17:46 2023 From: never at openjdk.org (Tom Rodriguez) Date: Thu, 20 Jul 2023 18:17:46 GMT Subject: RFR: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: <6V-Tbii4tAcrEFtxbp5zHQD5RpmxyAPqOulUrJ1It2Y=.15b3339a-3219-4de2-9f60-cd8ce3038a89@github.com> On Thu, 20 Jul 2023 18:12:10 GMT, Doug Simon wrote: >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 666: >> >>> 664: * entries do not have a symbol in the constant pool slot. >>> 665: */ >>> 666: return compilerToVM().lookupConstantInPool(this, cpi, true); >> >> This is true because it's always safe to do so? > > I don't really know what these "pseudo strings" are. In any case, I don't think resolving them involves calling any Java code. Sounds good. It's not currently causing any problems and we can investigate further if we start restricting when we `can_call_java` and problems show up here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1269809593 From gbarany at openjdk.org Mon Jul 24 19:03:45 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Mon, 24 Jul 2023 19:03:45 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects Message-ID: Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. ------------- Commit messages: - 8312579: [JVMCI] JVMCI support for virtual Vector API objects Changes: https://git.openjdk.org/jdk/pull/15003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312579 Stats: 23 lines in 4 files changed: 16 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15003/head:pull/15003 PR: https://git.openjdk.org/jdk/pull/15003 From dnsimon at openjdk.org Tue Jul 25 09:33:41 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 25 Jul 2023 09:33:41 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 18:58:02 GMT, Gerg? Barany wrote: > Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. > > Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. Marked as reviewed by dnsimon (Reviewer). src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java line 1036: > 1034: } > 1035: > 1036: private boolean isVector(Value vectorValue) { `vectorValue` -> `value` (otherwise the name seems to presume a true return value) ------------- PR Review: https://git.openjdk.org/jdk/pull/15003#pullrequestreview-1545034206 PR Review Comment: https://git.openjdk.org/jdk/pull/15003#discussion_r1273262605 From gbarany at openjdk.org Tue Jul 25 10:20:54 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Tue, 25 Jul 2023 10:20:54 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v2] In-Reply-To: References: Message-ID: > Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. > > Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. Gerg? Barany has updated the pull request incrementally with two additional commits since the last revision: - Improve parameter naming - Rewrite nested ternary expressions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15003/files - new: https://git.openjdk.org/jdk/pull/15003/files/5f183c27..87f81107 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=00-01 Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15003/head:pull/15003 PR: https://git.openjdk.org/jdk/pull/15003 From gbarany at openjdk.org Tue Jul 25 10:20:55 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Tue, 25 Jul 2023 10:20:55 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 09:29:57 GMT, Doug Simon wrote: >> Gerg? Barany has updated the pull request incrementally with two additional commits since the last revision: >> >> - Improve parameter naming >> - Rewrite nested ternary expressions > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java line 1036: > >> 1034: } >> 1035: >> 1036: private boolean isVector(Value vectorValue) { > > `vectorValue` -> `value` (otherwise the name seems to presume a true return value) done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15003#discussion_r1273317321 From xgong at openjdk.org Wed Jul 26 02:17:51 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 26 Jul 2023 02:17:51 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 10:20:54 GMT, Gerg? Barany wrote: >> Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. >> >> Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. > > Gerg? Barany has updated the pull request incrementally with two additional commits since the last revision: > > - Improve parameter naming > - Rewrite nested ternary expressions Does it need to update `#ifdef COMPILER2` to `#if COMPILER2_OR_JVMCI` in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1238 which is the gateway of re-materializing a Vector API object from vector register/stack? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15003#issuecomment-1650868591 From dnsimon at openjdk.org Wed Jul 26 07:56:42 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 07:56:42 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jul 2023 10:20:54 GMT, Gerg? Barany wrote: >> Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. >> >> Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. > > Gerg? Barany has updated the pull request incrementally with two additional commits since the last revision: > > - Improve parameter naming > - Rewrite nested ternary expressions Yes, I believe so. Gergo, you should scan all other code guarded by `EnableVectorSupport` to see if there's a similar problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15003#issuecomment-1651170939 From gbarany at openjdk.org Wed Jul 26 09:50:36 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Wed, 26 Jul 2023 09:50:36 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v2] In-Reply-To: References: Message-ID: <_glS7f67hE2dT0BlaXRp3PuOGocsqJEXm25_Hpo5-NY=.ed09564c-e8b5-4085-81e2-79b8711baffa@github.com> On Wed, 26 Jul 2023 02:15:13 GMT, Xiaohong Gong wrote: >> Gerg? Barany has updated the pull request incrementally with two additional commits since the last revision: >> >> - Improve parameter naming >> - Rewrite nested ternary expressions > > Does it need to update `#ifdef COMPILER2` to `#if COMPILER2_OR_JVMCI` in https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1238 which is the gateway of re-materializing a Vector API object from vector register/stack? I updated all the relevant places guarded by `EnableVectorSupport`. Thank you for pointing this out @XiaohongGong . ------------- PR Comment: https://git.openjdk.org/jdk/pull/15003#issuecomment-1651391821 From gbarany at openjdk.org Wed Jul 26 09:50:33 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Wed, 26 Jul 2023 09:50:33 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v3] In-Reply-To: References: Message-ID: > Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. > > Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. Gerg? Barany has updated the pull request incrementally with one additional commit since the last revision: Enable Vector API support code when JVMCI is defined ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15003/files - new: https://git.openjdk.org/jdk/pull/15003/files/87f81107..3172dfe8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=01-02 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15003/head:pull/15003 PR: https://git.openjdk.org/jdk/pull/15003 From gbarany at openjdk.org Wed Jul 26 10:25:00 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Wed, 26 Jul 2023 10:25:00 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v4] In-Reply-To: References: Message-ID: > Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. > > Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. Gerg? Barany has updated the pull request incrementally with one additional commit since the last revision: Fix #ifdef/#if mixup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15003/files - new: https://git.openjdk.org/jdk/pull/15003/files/3172dfe8..bd9f0c8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15003&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15003/head:pull/15003 PR: https://git.openjdk.org/jdk/pull/15003 From matsaave at openjdk.org Wed Jul 26 14:04:53 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 26 Jul 2023 14:04:53 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: On Thu, 20 Jul 2023 18:05:07 GMT, Doug Simon wrote: >> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: >> >> >> /** >> * Looks up a constant at the specified index. >> * >> * If {@code resolve == false} and the denoted constant is of type >> * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or >> * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then >> * {@code null} is returned. >> * >> * @param cpi the constant pool index >> * @return the {@code Constant} or {@code JavaType} instance representing the constant pool >> * entry >> */ >> Object lookupConstant(int cpi, boolean resolve); >> >> >> Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. >> >> --------- >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ >> `$ git checkout pull/14927` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/14927` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 14927` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 14927` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/14927.diff >> >>
> > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > avoid bootstrap method invocation by lookupBootstrapMethodInfo This looks good! I just have a few small questions and concerns. src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 700: > 698: C2V_END > 699: > 700: C2V_VMENTRY_NULL(jobject, lookupConstantInPool, (JNIEnv* env, jobject, ARGUMENT_PAIR(cp), jint index, bool resolve)) Maybe rename `jint index` to `cpi`, `cp_index`, or something related. I am currently making an effort to replace `index` with something more specific when used in relation to the Constant Pool, and I think it's best to exercise that here as well. src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 707: > 705: obj = cp->find_cached_constant_at(index, found_it, CHECK_NULL); > 706: if (!found_it) { > 707: return nullptr; Should there be some sort of exception or error checking here or in the caller? If the constant can't be found it either isn't resolved or the index is invalid, correct? src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1589: > 1587: C2V_END > 1588: > 1589: C2V_VMENTRY_0(int, invokeDynamicOperandToCPIndex, (JNIEnv* env, jobject, ARGUMENT_PAIR(cp), jint operand, jboolean resolve)) Is `invokeDynamicOperand` the correct name here? From what I recall, the operand to an `invokedynamic` instruction is a constant pool index which is later rewritten to an `indy_index`. I think the term operand can be confusing here. Given the way that this method works, the operand in question is always an encoded `indy_index`. ------------- PR Review: https://git.openjdk.org/jdk/pull/14927#pullrequestreview-1547792940 PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1274997653 PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1274993497 PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1275004183 From never at openjdk.org Wed Jul 26 14:53:43 2023 From: never at openjdk.org (Tom Rodriguez) Date: Wed, 26 Jul 2023 14:53:43 GMT Subject: RFR: 8312579: [JVMCI] JVMCI support for virtual Vector API objects [v4] In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 10:25:00 GMT, Gerg? Barany wrote: >> Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. >> >> Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. > > Gerg? Barany has updated the pull request incrementally with one additional commit since the last revision: > > Fix #ifdef/#if mixup Marked as reviewed by never (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15003#pullrequestreview-1547954097 From dnsimon at openjdk.org Wed Jul 26 15:43:42 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 15:43:42 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: On Wed, 26 Jul 2023 13:53:04 GMT, Matias Saavedra Silva wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid bootstrap method invocation by lookupBootstrapMethodInfo > > src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 707: > >> 705: obj = cp->find_cached_constant_at(index, found_it, CHECK_NULL); >> 706: if (!found_it) { >> 707: return nullptr; > > Should there be some sort of exception or error checking here or in the caller? If the constant can't be found it either isn't resolved or the index is invalid, correct? The error checking is already done by the call to `getTagAt` in `HotSpotConstantPool.lookupConstant(int cpi, boolean resolve)`. I'll add more javadoc to clarify when a null is returned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1275162660 From dnsimon at openjdk.org Wed Jul 26 16:00:20 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 16:00:20 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v3] In-Reply-To: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: > The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: > > > /** > * Looks up a constant at the specified index. > * > * If {@code resolve == false} and the denoted constant is of type > * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or > * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then > * {@code null} is returned. > * > * @param cpi the constant pool index > * @return the {@code Constant} or {@code JavaType} instance representing the constant pool > * entry > */ > Object lookupConstant(int cpi, boolean resolve); > > > Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ > `$ git checkout pull/14927` > > Update a local copy of the PR: \ > `$ git checkout pull/14927` \ > `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 14927` > > View PR using the GUI difftool: \ > `$ git pr show -t 14927` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/14927.diff > >
Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - clarified when null is returned by lookupConstantInPool - clarified naming around decoding an encoded indy index to a constant pool index - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8312235 - avoid bootstrap method invocation by lookupBootstrapMethodInfo - update TestDynamicConstant to test new ConstantPool.lookupConstant method - add ConstantPool.lookupConstant(int cpi, boolean resolve) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14927/files - new: https://git.openjdk.org/jdk/pull/14927/files/4621c13a..5ada646c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=01-02 Stats: 30527 lines in 565 files changed: 16752 ins; 11706 del; 2069 mod Patch: https://git.openjdk.org/jdk/pull/14927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927 PR: https://git.openjdk.org/jdk/pull/14927 From dnsimon at openjdk.org Wed Jul 26 16:00:20 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 16:00:20 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: On Wed, 26 Jul 2023 15:41:13 GMT, Doug Simon wrote: >> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 707: >> >>> 705: obj = cp->find_cached_constant_at(index, found_it, CHECK_NULL); >>> 706: if (!found_it) { >>> 707: return nullptr; >> >> Should there be some sort of exception or error checking here or in the caller? If the constant can't be found it either isn't resolved or the index is invalid, correct? > > The error checking is already done by the call to `getTagAt` in `HotSpotConstantPool.lookupConstant(int cpi, boolean resolve)`. > I'll add more javadoc to clarify when a null is returned. Note that the javadoc of `lookupConstantInPool` already states: * The behavior of this method is undefined if {@code cpi} does not denote one of the following * entry types: {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_String}, * {@code JVM_CONSTANT_MethodHandle}, {@code JVM_CONSTANT_MethodHandleInError}, * {@code JVM_CONSTANT_MethodType} and {@code JVM_CONSTANT_MethodTypeInError}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1275176566 From dnsimon at openjdk.org Wed Jul 26 16:00:21 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 16:00:21 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v2] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> <37fawNo9anSeBjPYP7tn-wcCUFp4UobyMq39dHvBJAg=.d90c0d6f-5c2b-407e-a730-d44dd7a7d4b5@github.com> Message-ID: <8PFCQ8MOx49lqLdB_n6Od8b50mH3CApzOaNBFiSZRm8=.20b58d4a-a027-4bac-9153-b98260a5958f@github.com> On Wed, 26 Jul 2023 14:00:34 GMT, Matias Saavedra Silva wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> avoid bootstrap method invocation by lookupBootstrapMethodInfo > > src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1589: > >> 1587: C2V_END >> 1588: >> 1589: C2V_VMENTRY_0(int, invokeDynamicOperandToCPIndex, (JNIEnv* env, jobject, ARGUMENT_PAIR(cp), jint operand, jboolean resolve)) > > Is `invokeDynamicOperand` the correct name here? From what I recall, the operand to an `invokedynamic` instruction is a constant pool index which is later rewritten to an `indy_index`. I think the term operand can be confusing here. > > Given the way that this method works, the operand in question is always an encoded `indy_index`. I've pushed a commit with better naming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14927#discussion_r1275179670 From dnsimon at openjdk.org Wed Jul 26 16:11:11 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 26 Jul 2023 16:11:11 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v4] In-Reply-To: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: > The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: > > > /** > * Looks up a constant at the specified index. > * > * If {@code resolve == false} and the denoted constant is of type > * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or > * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then > * {@code null} is returned. > * > * @param cpi the constant pool index > * @return the {@code Constant} or {@code JavaType} instance representing the constant pool > * entry > */ > Object lookupConstant(int cpi, boolean resolve); > > > Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ > `$ git checkout pull/14927` > > Update a local copy of the PR: \ > `$ git checkout pull/14927` \ > `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 14927` > > View PR using the GUI difftool: \ > `$ git pr show -t 14927` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/14927.diff > >
Doug Simon has updated the pull request incrementally with one additional commit since the last revision: renamed index to cp_index ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14927/files - new: https://git.openjdk.org/jdk/pull/14927/files/5ada646c..1ca9ab68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14927&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927 PR: https://git.openjdk.org/jdk/pull/14927 From matsaave at openjdk.org Wed Jul 26 16:24:42 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 26 Jul 2023 16:24:42 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v4] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: On Wed, 26 Jul 2023 16:11:11 GMT, Doug Simon wrote: >> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: >> >> >> /** >> * Looks up a constant at the specified index. >> * >> * If {@code resolve == false} and the denoted constant is of type >> * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or >> * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then >> * {@code null} is returned. >> * >> * @param cpi the constant pool index >> * @return the {@code Constant} or {@code JavaType} instance representing the constant pool >> * entry >> */ >> Object lookupConstant(int cpi, boolean resolve); >> >> >> Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. >> >> --------- >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ >> `$ git checkout pull/14927` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/14927` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 14927` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 14927` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/14927.diff >> >>
> > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > renamed index to cp_index Thank you for the changes, approved! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/14927#pullrequestreview-1548144467 From never at openjdk.org Wed Jul 26 16:40:53 2023 From: never at openjdk.org (Tom Rodriguez) Date: Wed, 26 Jul 2023 16:40:53 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v4] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: On Wed, 26 Jul 2023 16:11:11 GMT, Doug Simon wrote: >> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: >> >> >> /** >> * Looks up a constant at the specified index. >> * >> * If {@code resolve == false} and the denoted constant is of type >> * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or >> * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then >> * {@code null} is returned. >> * >> * @param cpi the constant pool index >> * @return the {@code Constant} or {@code JavaType} instance representing the constant pool >> * entry >> */ >> Object lookupConstant(int cpi, boolean resolve); >> >> >> Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. >> >> --------- >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ >> `$ git checkout pull/14927` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/14927` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 14927` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 14927` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/14927.diff >> >>
> > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > renamed index to cp_index Marked as reviewed by never (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14927#pullrequestreview-1548172519 From dnsimon at openjdk.org Thu Jul 27 08:42:01 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 27 Jul 2023 08:42:01 GMT Subject: RFR: 8312235: [JVMCI] ConstantPool should not force eager resolution [v4] In-Reply-To: References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: <3zHPbZa6SeEVeNdxtMJWNuLUr_ntmx-0ds-KUOkix8w=.605bf7a8-78ec-4dca-b078-b0caf5d63d04@github.com> On Wed, 26 Jul 2023 16:11:11 GMT, Doug Simon wrote: >> The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: >> >> >> /** >> * Looks up a constant at the specified index. >> * >> * If {@code resolve == false} and the denoted constant is of type >> * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or >> * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then >> * {@code null} is returned. >> * >> * @param cpi the constant pool index >> * @return the {@code Constant} or {@code JavaType} instance representing the constant pool >> * entry >> */ >> Object lookupConstant(int cpi, boolean resolve); >> >> >> Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. >> >> --------- >> ### Progress >> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ >> `$ git checkout pull/14927` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/14927` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` >> >>
>>
Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 14927` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 14927` >> >>
>>
Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/14927.diff >> >>
> > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > renamed index to cp_index Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14927#issuecomment-1653163435 From dnsimon at openjdk.org Thu Jul 27 08:42:02 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 27 Jul 2023 08:42:02 GMT Subject: Integrated: 8312235: [JVMCI] ConstantPool should not force eager resolution In-Reply-To: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> References: <9zF7nYvZ2ZU7gIquOEdKlAhyyX2AQ3pVmnwKh9Yz4aI=.192df7cb-66aa-43e3-8d3d-58ffa18b8617@github.com> Message-ID: On Tue, 18 Jul 2023 20:35:54 GMT, Doug Simon wrote: > The existing `jdk.vm.ci.meta.ConstantPool.lookupConstant(int cpi)` method forces eager resolving of constants. For `DynamicConstant`, `MethodHandle` and `MethodType`, this can mean invoking bootstrap methods, something that should not be done during JIT compilation. To avoid this, this PR adds the following to `jdk.vm.ci.meta.ConstantPool`: > > > /** > * Looks up a constant at the specified index. > * > * If {@code resolve == false} and the denoted constant is of type > * {@code JVM_CONSTANT_Dynamic}, {@code JVM_CONSTANT_MethodHandle} or > * {@code JVM_CONSTANT_MethodType} and it's not yet resolved then > * {@code null} is returned. > * > * @param cpi the constant pool index > * @return the {@code Constant} or {@code JavaType} instance representing the constant pool > * entry > */ > Object lookupConstant(int cpi, boolean resolve); > > > Likewise, `jdk.vm.ci.meta.ConstantPool.lookupBootstrapMethodInvocation` has been fixed to no longer invoke the associated bootstrap method. > > --------- > ### Progress > - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/14927/head:pull/14927` \ > `$ git checkout pull/14927` > > Update a local copy of the PR: \ > `$ git checkout pull/14927` \ > `$ git pull https://git.openjdk.org/jdk.git pull/14927/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 14927` > > View PR using the GUI difftool: \ > `$ git pr show -t 14927` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/14927.diff > >
This pull request has now been integrated. Changeset: 86821a7c Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/86821a7ce89c51cc3650228c55a4a88c743209e4 Stats: 458 lines in 8 files changed: 260 ins; 157 del; 41 mod 8312235: [JVMCI] ConstantPool should not force eager resolution Reviewed-by: never, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/14927 From gbarany at openjdk.org Thu Jul 27 10:50:56 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Thu, 27 Jul 2023 10:50:56 GMT Subject: Integrated: 8312579: [JVMCI] JVMCI support for virtual Vector API objects In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 18:58:02 GMT, Gerg? Barany wrote: > Optimized Vector API values are represented as raw values in SIMD registers. When deoptimizing with such a value in the state, a Java heap object must be recreated. HotSpot has a special "Location::vector" location type to mark Vector API values, and it knows how to materialize such values. > > Extend the JVMCI code installer to mark the appropriate values as vectors so that JVMCI-compiled code can also deoptimize with Vector API values in SIMD registers. This pull request has now been integrated. Changeset: 271417a0 Author: Gerg? Barany Committer: Doug Simon URL: https://git.openjdk.org/jdk/commit/271417a0e10245504e41c98c65941d5fe21f33ac Stats: 49 lines in 7 files changed: 34 ins; 0 del; 15 mod 8312579: [JVMCI] JVMCI support for virtual Vector API objects Reviewed-by: dnsimon, never ------------- PR: https://git.openjdk.org/jdk/pull/15003 From jwaters at openjdk.org Fri Jul 28 07:32:04 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Jul 2023 07:32:04 GMT Subject: RFR: 8313302: Fix formatting errors on Windows Message-ID: Fix several formatting errors on Windows ------------- Commit messages: - 8313302 Changes: https://git.openjdk.org/jdk/pull/15063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313302 Stats: 128 lines in 14 files changed: 0 ins; 0 del; 128 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From jwaters at openjdk.org Fri Jul 28 07:43:04 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Jul 2023 07:43:04 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v2] In-Reply-To: References: Message-ID: > Fix several formatting errors on Windows Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15063/files - new: https://git.openjdk.org/jdk/pull/15063/files/39548d5c..d6bff320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From jwaters at openjdk.org Fri Jul 28 07:50:19 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Jul 2023 07:50:19 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: Message-ID: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> > Fix several formatting errors on Windows Julian Waters has updated the pull request incrementally with one additional commit since the last revision: zPhysicalMemoryBacking_windows.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15063/files - new: https://git.openjdk.org/jdk/pull/15063/files/d6bff320..db9102a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From stuefe at openjdk.org Fri Jul 28 09:51:56 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Jul 2023 09:51:56 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp Hi Julian, I'm sorry, but I object to this change. It is another heap of aesthetic changes, with very very few changes actually needed (see inline remarks). Contrary to the title, it also touches shared code, and there are (almost) no errors to fix. And the one arguably incorrect place, in code heap, is not a "formatting error on windows". Please consider that your aesthetic taste is not shared by everyone, but changes like these cause a lot of work for others. Cheers, Thomas src/hotspot/os/windows/gc/x/xMapper_windows.cpp line 118: > 116: const uintptr_t addr = map_view_no_placeholder(file_handle, file_offset, size); > 117: if (addr == 0) { > 118: log_error(gc)("Failed to map view of paging file mapping (%ld)", GetLastError()); Here, and in many other places: All these `%d` -> `%ld` changes are questionable. Why do you think `l` is more correct? Strictly spoken both existing and your versions are incorrect since GetLastError returns a DWORD, which is an unsigned 32-bit integer. Were I to change anything, I would print an unsigned integer. But I would not change anything, since all documented error codes are well below 0x8000_0000. I think we are good here. src/hotspot/os/windows/gc/x/xMapper_windows.cpp line 253: > 251: > 252: if (!res) { > 253: fatal("Failed to unreserve memory: " INTPTR_FORMAT " " SIZE_FORMAT "M (%ld)", Here, and in many other places: PTR_FORMAT -> INTPTR_FORMAT is pointless, since both macros are the same. We use PTR_FORMAT in many many places to print pointers. I prefer it to INTPTR_FORMAT, since it does not convey the assumption of a type. After all, the type does not matter: we just print the pointer as a raw hex value. Also, INTPTR suggests intptr_t which suggests signedness, which has no place here. *If* we want to change this, we should first agree on the INTPTR_FORMAT vs PTR_FORMAT difference. And why we use intptr_t in many places that actually call for an uintptr_t. But I would not change it. There is no need. src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267: > 265: > 266: if (!res) { > 267: fatal_error("Failed to split placeholder", untype(addr), size); Please don't. `untype` does an assertion check. We don't want that here, when constructing arguments for a fatal error message. src/hotspot/os/windows/osThread_windows.hpp line 30: > 28: typedef void* HANDLE; > 29: public: > 30: typedef unsigned int thread_id_t; Since Windows is LLP64, this has no effect, even though beginthreadex returns an unsigned int. src/hotspot/os/windows/os_windows.cpp line 3382: > 3380: if (Verbose && PrintMiscellaneous) { > 3381: reserveTimer.stop(); > 3382: tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes, SIZE_FORMAT. src/hotspot/os/windows/perfMemory_windows.cpp line 259: > 257: if (PrintMiscellaneous && Verbose) { > 258: warning("%s is not a directory, file attributes = " > 259: "0x%08lx\n", path, fa); UINT32_FORMAT src/hotspot/os/windows/symbolengine.cpp line 635: > 633: } else { > 634: st->print("initialized successfully"); > 635: st->print(" - sym options: 0x%lX", WindowsDbgHelp::symGetOptions()); No. SymGetOptions returns a DWORD, X is correct here. src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 422: > 420: st->print(", RBX=0x%016llx", uc->Rbx); > 421: st->print(", RCX=0x%016llx", uc->Rcx); > 422: st->print(", RDX=0x%016llx", uc->Rdx); Why? src/hotspot/share/code/codeHeapState.cpp line 1334: > 1332: if (SizeDistributionArray != nullptr) { > 1333: unsigned long total_count = 0; > 1334: uint64_t total_size = 0; This is a functional change (actually the only one I could spot), and it increases the size of this type to 64-bit on Windows. It may also be incorrect, since on 32-bit platforms you probably don't want 64-bit here. The correct type to use would be size_t. Since this change is hidden in a deluge of unnecessary cosmetic changes, if we feel this is needed, this should be addressed in a separate RFE. But then again, probably not: code cache size is limited to 32-bit, and I bet we have a lot more places to change if we wanted to change that. Also way out of scope for the RFE description. src/hotspot/share/code/codeHeapState.cpp line 1387: > 1385: " occupied space) is used by the blocks in the given size range.\n" > 1386: " %ld characters are printed per percentage point.\n", pctFactor/100); > 1387: ast->print_cr("total size of all blocks: " INT64_FORMAT_W(7) "M", (total_size< References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: <6B76iPop_OLgdGhVzafFiOMStv1CAVVQZ4z7AjxOPE0=.1585baa3-dd5d-4778-8e9a-772846ae6c3f@github.com> On Fri, 28 Jul 2023 09:46:47 GMT, Thomas Stuefe wrote: > Hi Julian, > > I'm sorry, but I object to this change. > > It is another heap of aesthetic changes, with very very few changes actually needed (see inline remarks). Contrary to the title, it also touches shared code, and there are (almost) no errors to fix. And the one arguably incorrect place, in code heap, is not a "formatting error on windows". > > Please consider that your aesthetic taste is not shared by everyone, but changes like these cause a lot of work for others. > > Cheers, Thomas Hi Thomas, Sigh, I was afraid of that. I've not been putting out good quality changes lately :( I will mention that these are not merely aesthetic changes however, but actually is an effort spawned out of JDK-8288293, since all of these are flagged as formatting errors. It may be the case that I'm putting a bit too much faith in gcc's format checking, but I do want to discuss the rest in the review comments since it is a bit easier > src/hotspot/os/windows/gc/x/xMapper_windows.cpp line 118: > >> 116: const uintptr_t addr = map_view_no_placeholder(file_handle, file_offset, size); >> 117: if (addr == 0) { >> 118: log_error(gc)("Failed to map view of paging file mapping (%ld)", GetLastError()); > > Here, and in many other places: > > All these `%d` -> `%ld` changes are questionable. Why do you think `l` is more correct? > > Strictly spoken both existing and your versions are incorrect since GetLastError returns a DWORD, which is an unsigned 32-bit integer. > > Were I to change anything, I would print an unsigned integer. But I would not change anything, since all documented error codes are well below 0x8000_0000. I think we are good here. DWORD is defined as an unsigned long on all Windows compilers, which more accurately maps to %ld under C++ rules. This was more for correctness, but may not be strictly needed ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1655418084 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277359872 From jwaters at openjdk.org Fri Jul 28 10:11:44 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Jul 2023 10:11:44 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 09:24:33 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> zPhysicalMemoryBacking_windows.cpp > > src/hotspot/os/windows/osThread_windows.hpp line 30: > >> 28: typedef void* HANDLE; >> 29: public: >> 30: typedef unsigned int thread_id_t; > > Since Windows is LLP64, this has no effect, even though beginthreadex returns an unsigned int. It's also another formatting change, as this is printed as %d in shared code. This also matches the definition of int on other platforms. This should functionally be harmless, because ints are promoted to longs (DWORD) whenever thread_id_t is passed to a callee that expects a DWORD, and since longs are the same size as ints this is effectively an implicit cast with no effect in those cases > src/hotspot/os/windows/perfMemory_windows.cpp line 259: > >> 257: if (PrintMiscellaneous && Verbose) { >> 258: warning("%s is not a directory, file attributes = " >> 259: "0x%08lx\n", path, fa); > > UINT32_FORMAT Noted, if this is accepted > src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 422: > >> 420: st->print(", RBX=0x%016llx", uc->Rbx); >> 421: st->print(", RCX=0x%016llx", uc->Rcx); >> 422: st->print(", RDX=0x%016llx", uc->Rdx); > > Why? All of these are either DWORD64 or DWORD, none are actually intptr_t's or uintptr_t's > src/hotspot/share/code/codeHeapState.cpp line 1334: > >> 1332: if (SizeDistributionArray != nullptr) { >> 1333: unsigned long total_count = 0; >> 1334: uint64_t total_size = 0; > > This is a functional change (actually the only one I could spot), and it increases the size of this type to 64-bit on Windows. > > It may also be incorrect, since on 32-bit platforms you probably don't want 64-bit here. The correct type to use would be size_t. > > Since this change is hidden in a deluge of unnecessary cosmetic changes, if we feel this is needed, this should be addressed in a separate RFE. > > But then again, probably not: code cache size is limited to 32-bit, and I bet we have a lot more places to change if we wanted to change that. > > Also way out of scope for the RFE description. For this one (and the one below) I couldn't figure out whether the intention was for a 32 or 64 bit number in this case. This would be 64 bit on every platform but on Windows, which is 32 bit, and the code directly below this also faces the same issue too, is this intentional? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277362853 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277363449 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277364035 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277365355 From stuefe at openjdk.org Fri Jul 28 10:25:41 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Jul 2023 10:25:41 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp > > Hi Julian, > > I'm sorry, but I object to this change. > > It is another heap of aesthetic changes, with very very few changes actually needed (see inline remarks). Contrary to the title, it also touches shared code, and there are (almost) no errors to fix. And the one arguably incorrect place, in code heap, is not a "formatting error on windows". > > Please consider that your aesthetic taste is not shared by everyone, but changes like these cause a lot of work for others. > > Cheers, Thomas > > Hi Thomas, > > Sigh, I was afraid of that. I've not been putting out good quality changes lately :( I will mention that these are not merely aesthetic changes however, but actually is an effort spawned out of JDK-8288293, since all of these are flagged as formatting errors. It may be the case that I'm putting a bit too much faith in gcc's format checking, but I do want to discuss the rest in the review comments since it is a bit easier So the point of this change is to satisfy gcc on Windows? Accomodating a new build platform, making (and keeping!) it warning-free is a considerable effort. Even if you do it, it has a lot of side effects on others: reviewer churn, accidental bugs, makes backports more difficult... For smallish things its okay, but if it keeps causing massive changes like this one we should discuss this first. In my eyes, this is similar to adding a new platform, for which the bar is very (it is technically less complex than a new platform, but OTOH it is also less isolated). As a side note, I think I mentioned this before, but it would be very helpful if you would put more love into your JBS issue descriptions and - texts. Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1655447802 From stuefe at openjdk.org Fri Jul 28 10:34:51 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Jul 2023 10:34:51 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 10:06:01 GMT, Julian Waters wrote: >> src/hotspot/os/windows/osThread_windows.hpp line 30: >> >>> 28: typedef void* HANDLE; >>> 29: public: >>> 30: typedef unsigned int thread_id_t; >> >> Since Windows is LLP64, this has no effect, even though beginthreadex returns an unsigned int. > > It's also another formatting change, as this is printed as %d in shared code. This also matches the definition of int on other platforms. This should functionally be harmless, because ints are promoted to longs (DWORD) whenever thread_id_t is passed to a callee that expects a DWORD, and since longs are the same size as ints this is effectively an implicit cast with no effect in those cases I can live with this change. Its also small and isolated. >> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 422: >> >>> 420: st->print(", RBX=0x%016llx", uc->Rbx); >>> 421: st->print(", RCX=0x%016llx", uc->Rcx); >>> 422: st->print(", RDX=0x%016llx", uc->Rdx); >> >> Why? > > All of these are either DWORD64 or DWORD, none are actually intptr_t's or uintptr_t's In that case UINT64_FORMAT_X would be more correct. But again, unless there is an important reason to do so, I would leave changing this to when someone changes/moves around the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277382451 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277384588 From jwaters at openjdk.org Fri Jul 28 10:40:52 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 28 Jul 2023 10:40:52 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp Hi Thomas, > So the point of this change is to satisfy gcc on Windows? Accomodating a new build platform, making (and keeping!) it warning-free is a considerable effort. Even if you do it, it has a lot of side effects on others: reviewer churn, accidental bugs, makes backports more difficult... Not really, I was perfectly capable of solving these issues by silencing the error checker in compilerWarnings_gcc.hpp (see ATTRIBUTE_PRINTF and ATTRIBUTE_SCANF), I decided not to do so since I believed these were reasonable changes as the time to fix the formatting on Windows, I was not aware of the actual scale the finished change would be on. I can retract this change if need be, it's not critical to the Project > For smallish things its okay, but if it keeps causing massive changes like this one we should discuss this first. In my eyes, this is similar to adding a new platform, for which the bar is very high (it is technically less complex than a new platform, but OTOH it is also less isolated). Where would changes like these be discussed? As far as I know, I'm really the only one working on a Project like this. As a side note, the actual changes to HotSpot to get it compiling on gcc are actually minimal, this is technically not one of those changes, and a good chunk of them have already been integrated into mainline Should I take the rest of this to build-dev? Thanks for your time, Julian ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1655466004 From stuefe at openjdk.org Fri Jul 28 10:40:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Jul 2023 10:40:54 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 10:08:56 GMT, Julian Waters wrote: >> src/hotspot/share/code/codeHeapState.cpp line 1334: >> >>> 1332: if (SizeDistributionArray != nullptr) { >>> 1333: unsigned long total_count = 0; >>> 1334: uint64_t total_size = 0; >> >> This is a functional change (actually the only one I could spot), and it increases the size of this type to 64-bit on Windows. >> >> It may also be incorrect, since on 32-bit platforms you probably don't want 64-bit here. The correct type to use would be size_t. >> >> Since this change is hidden in a deluge of unnecessary cosmetic changes, if we feel this is needed, this should be addressed in a separate RFE. >> >> But then again, probably not: code cache size is limited to 32-bit, and I bet we have a lot more places to change if we wanted to change that. >> >> Also way out of scope for the RFE description. > > For this one (and the one below) I couldn't figure out whether the intention was for a 32 or 64 bit number in this case. This would be 64 bit on every platform but on Windows, which is 32 bit, and the code directly below this also faces the same issue too, is this intentional? long is 32-bit on Linux x86 and arm32 too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1277388936 From stuefe at openjdk.org Fri Jul 28 12:42:50 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Jul 2023 12:42:50 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 10:38:03 GMT, Julian Waters wrote: > > Hi Thomas, > > > So the point of this change is to satisfy gcc on Windows? Accomodating a new build platform, making (and keeping!) it warning-free is a considerable effort. Even if you do it, it has a lot of side effects on others: reviewer churn, accidental bugs, makes backports more difficult... > > Not really, I was perfectly capable of solving these issues by silencing the error checker in compilerWarnings_gcc.hpp (see ATTRIBUTE_PRINTF and ATTRIBUTE_SCANF), I decided not to do so since I believed these were reasonable changes as the time to fix the formatting on Windows, I was not aware of the actual scale the finished change would be on. I can retract this change if need be, it's not critical to the Project > > > For smallish things its okay, but if it keeps causing massive changes like this one we should discuss this first. In my eyes, this is similar to adding a new platform, for which the bar is very high (it is technically less complex than a new platform, but OTOH it is also less isolated). > > Where would changes like these be discussed? As far as I know, I'm really the only one working on a Project like this. As a side note, the actual changes to HotSpot to get it compiling on gcc are actually minimal, this is technically not one of those changes, and a good chunk of them have already been integrated into mainline > > Should I take the rest of this to build-dev? > For discussing things that relate to hotspot coding, e.g. INTPTR_FORMAT, hotspot-dev would be better. > Thanks for your time, Julian No problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1655623178 From kbarrett at openjdk.org Sat Jul 29 00:41:02 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 29 Jul 2023 00:41:02 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: <-_YAKPEFAUT7HCxmF4iFxdyyyYfK6uK7sMNY044C0HE=.be47a1e4-ff65-4efd-b897-c35262203d1b@github.com> On Fri, 28 Jul 2023 10:36:12 GMT, Thomas Stuefe wrote: >> For this one (and the one below) I couldn't figure out whether the intention was for a 32 or 64 bit number in this case. This would be 64 bit on every platform but on Windows, which is 32 bit, and the code directly below this also faces the same issue too, is this intentional? > > long is 32-bit on Linux x86 and arm32 too. [not a review, just a drive-by comment] The type `long` really shouldn't be used in shared code. There have been discussions and maybe some efforts to nuke uses, but having just done the grep, there are still quite a few. The one in question might actually be an appropriate place to use `uintx`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1278191849 From jwaters at openjdk.org Sat Jul 29 04:59:57 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Jul 2023 04:59:57 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp Will close and address the issues discovered in this change individually ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1656556048 From jwaters at openjdk.org Sat Jul 29 04:59:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Jul 2023 04:59:58 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <-_YAKPEFAUT7HCxmF4iFxdyyyYfK6uK7sMNY044C0HE=.be47a1e4-ff65-4efd-b897-c35262203d1b@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> <-_YAKPEFAUT7HCxmF4iFxdyyyYfK6uK7sMNY044C0HE=.be47a1e4-ff65-4efd-b897-c35262203d1b@github.com> Message-ID: On Sat, 29 Jul 2023 00:38:18 GMT, Kim Barrett wrote: >> long is 32-bit on Linux x86 and arm32 too. > > [not a review, just a drive-by comment] > The type `long` really shouldn't be used in shared code. There have been discussions and maybe some efforts > to nuke uses, but having just done the grep, there are still quite a few. The one in question might actually be an > appropriate place to use `uintx`. Hi Kim, mind if you share the grep command for that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1278246025 From jwaters at openjdk.org Sat Jul 29 04:59:59 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 29 Jul 2023 04:59:59 GMT Subject: Withdrawn: 8313302: Fix formatting errors on Windows In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 07:25:26 GMT, Julian Waters wrote: > Fix several formatting errors on Windows This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15063