From dnsimon at openjdk.org Sun Sep 1 09:50:55 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Sun, 1 Sep 2024 09:50:55 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions Message-ID: This PR modifies the GitHub Actions' linux product build to include building of the static-libs bundle as a minimal smoke test that these builds don't break. ------------- Commit messages: - build static-libs on linux Changes: https://git.openjdk.org/jdk/pull/20803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20803&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337265 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20803/head:pull/20803 PR: https://git.openjdk.org/jdk/pull/20803 From jwaters at openjdk.org Sun Sep 1 16:33:24 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 1 Sep 2024 16:33:24 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323416932 From ihse at openjdk.org Sun Sep 1 21:35:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 1 Sep 2024 21:35:02 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: > The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html. > > Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated. > > The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. > > I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix bad change in BuildMicrobenchmarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20798/files - new: https://git.openjdk.org/jdk/pull/20798/files/0cbd0923..f25fa856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20798&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20798&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20798.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20798/head:pull/20798 PR: https://git.openjdk.org/jdk/pull/20798 From ihse at openjdk.org Sun Sep 1 21:35:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 1 Sep 2024 21:35:02 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 20:19:46 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bad change in BuildMicrobenchmarks > > make/test/BuildMicrobenchmark.gmk line 71: > >> 69: # Need double \n to get new lines and no trailing spaces >> 70: MICROBENCHMARK_MANIFEST := Build: $(FULL_VERSION)\n \ >> 71: \nJMH-Version: $(JMH_VERSION)\n \ > > Are you sure these spaces are safe? The comment mentions trailing spaces as something undesired and depending on how this is used, I suspect adding a space between the \n could interfere with that. Now that I look at this again, I realize the broken lines start at position 1. That indicates that the original author did not want to indent the line as it "should" have been, just to make sure that no extra space were added. So you are likely correct; this was a bad change. Thanks for spotting it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20798#discussion_r1740197216 From ihse at openjdk.org Sun Sep 1 21:37:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 1 Sep 2024 21:37:18 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: <1dW6JjfxSaQqjRxdfWBgiiO7R7mOSWoQIr7ShKnpxQE=.018b3f44-d6ee-4f70-809b-0eab44c85dcb@github.com> On Fri, 30 Aug 2024 19:29:56 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bad change in BuildMicrobenchmarks > > make/MainSupport.gmk line 202: > >> 200: $(foreach i, 2 3 4 5 6 7 8, $(if $(strip $($i)),$(strip $1)_$(strip $($i)))$(NEWLINE)) >> 201: $(if $(9), $(error Internal makefile error: Too many arguments to \ >> 202: DeclareRecipesForPhase, please update MakeHelper.gmk)) > > I know this is a whitespace cleanup, so this should likely be addressed in a separate issue, but this error message is referencing `MakeHelper.gmk` while being in the file `MainSupport.gmk`. Also, shouldn't this be able to use the `NamedParamsMacroTemplate` instead of using this old technique for named arguments? Yes, I agree on all accounts. We have some other places left as well where `NamedParamsMacroTemplate` is not used even though it should be. Feel free to open a bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20798#discussion_r1740197840 From dholmes at openjdk.org Mon Sep 2 04:12:26 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 2 Sep 2024 04:12:26 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Sun, 1 Sep 2024 16:30:33 GMT, Julian Waters wrote: > This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work Wouldn't such link-time "inlining" only appear in the object code stored within the library, not in the original object file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323775705 From jwaters at openjdk.org Mon Sep 2 04:15:21 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Sep 2024 04:15:21 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: On Mon, 2 Sep 2024 04:09:19 GMT, David Holmes wrote: > > This does make me wonder: What if the new method for checking if the VM was statically linked was inlined? Then the problem comes back yet again as the object files need to be recompiled once more. This is possible if Link Time Optimization is switched on, and I don't like the implication that LTO might be removed as a result just to make this work > > Wouldn't such link-time "inlining" only appear in the object code stored within the library, not in the original object file? Ah, you're right, good catch. I got mixed up with the implementation details of different compilers there, sorry ------------- PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2323778397 From ihse at openjdk.org Mon Sep 2 09:04:20 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 09:04:20 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 21:35:02 GMT, Magnus Ihse Bursie wrote: >> The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html. >> >> Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated. >> >> The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. >> >> I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix bad change in BuildMicrobenchmarks Running compare builds sounds like a good safety measure. I've done that now, and it looks clean on all platforms. (With one exception: we include the vardeps files for jar files in jdk/demos -- historical reasons, I assume -- and they look slightly different; but they should not really have been included in the comparison anyway so it does not matter.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20798#issuecomment-2324197646 From ihse at openjdk.org Mon Sep 2 09:04:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 09:04:21 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: <1dW6JjfxSaQqjRxdfWBgiiO7R7mOSWoQIr7ShKnpxQE=.018b3f44-d6ee-4f70-809b-0eab44c85dcb@github.com> References: <1dW6JjfxSaQqjRxdfWBgiiO7R7mOSWoQIr7ShKnpxQE=.018b3f44-d6ee-4f70-809b-0eab44c85dcb@github.com> Message-ID: On Sun, 1 Sep 2024 21:34:48 GMT, Magnus Ihse Bursie wrote: >> make/MainSupport.gmk line 202: >> >>> 200: $(foreach i, 2 3 4 5 6 7 8, $(if $(strip $($i)),$(strip $1)_$(strip $($i)))$(NEWLINE)) >>> 201: $(if $(9), $(error Internal makefile error: Too many arguments to \ >>> 202: DeclareRecipesForPhase, please update MakeHelper.gmk)) >> >> I know this is a whitespace cleanup, so this should likely be addressed in a separate issue, but this error message is referencing `MakeHelper.gmk` while being in the file `MainSupport.gmk`. Also, shouldn't this be able to use the `NamedParamsMacroTemplate` instead of using this old technique for named arguments? > > Yes, I agree on all accounts. We have some other places left as well where `NamedParamsMacroTemplate` is not used even though it should be. Feel free to open a bug. I opened https://bugs.openjdk.org/browse/JDK-8339370 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20798#discussion_r1740570425 From ihse at openjdk.org Mon Sep 2 09:17:28 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 09:17:28 GMT Subject: Integrated: 8338768: Introduce runtime lookup to check for static builds In-Reply-To: References: Message-ID: <7ZCNx3fBoTkmUDxGYAcN6eqygCSF-kxH3vBPSczQqaA=.85487425-1e4f-4496-92f7-92d7a6d69156@github.com> On Wed, 21 Aug 2024 21:53:39 GMT, Magnus Ihse Bursie wrote: > As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. > > This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. > > This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. This pull request has now been integrated. Changeset: a136a85b Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5 Stats: 205 lines in 12 files changed: 109 ins; 21 del; 75 mod 8338768: Introduce runtime lookup to check for static builds Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jiangli Zhou Reviewed-by: prr, jiangli, alanb ------------- PR: https://git.openjdk.org/jdk/pull/20666 From ihse at openjdk.org Mon Sep 2 10:22:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 10:22:18 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 20:23:29 GMT, Erik Joelsson wrote: > also manually verified a few incremental build scenarios, including running tests. I have tested changing: * a hotspot file * a JDK library native file * a JDK module java file and verified that the correct bits get rebuilt. I have also verified that running tests work, including after all these incremental rebuilds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20798#issuecomment-2324366938 From ihse at openjdk.org Mon Sep 2 10:59:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 10:59:18 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote: > This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. > This is a minimal smoke test to ensure these builds don't break. The code looks fine. However, the problem with GHA is that it is easy to add a test of your own special case which everyone else will run for all foreseeable future. But if everyone added their favorite platform/test, GHA would be unusable due to being too slow. So my general attitude when someone wants to slow down GHA is: Explain to me -- and others -- why this use case is so important that everyone's GHA runs should spend cycles on it. I'm not saying this won't be accepted, but I am saying that you need to provide a solid rationale. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20803#issuecomment-2324440161 From ihse at openjdk.org Mon Sep 2 11:03:17 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 11:03:17 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: <-E_SPEBIwKJIeGbguQqesZK2Dq6chOR5zM_NHc9lZ80=.58e76ebe-30fc-48af-8252-e01fc5d98a4d@github.com> On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote: > This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. > This is a minimal smoke test to ensure these builds don't break. Also, you might not be aware of this, but I am working on a redesign of how static libraries are built in the JDK. This has been long overdue but have been put into sharp contrast by the Hermetic Java project. The long-term plan is to compile the .o files only onces, and then link them twice, once for normal dynamic libs, and once for static libs. This will make building static libs essentially free, and when that happens, enabling them on GHA is a no-brainer. It have only been making slow progress towards that goal due to a number of factors, so I cannot promise that it will done by any specific date, but it is a high priority task for me. So you can either try to argue that this should be enabled already, even though it costs extra cycles, or you can wait until the static libs redesign is done, and it will be enabled for free. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20803#issuecomment-2324447735 From mbaesken at openjdk.org Mon Sep 2 11:48:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Sep 2024 11:48:48 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings Message-ID: We get a couple of warnings as errors on AIX because of unused variables or functions , for example : /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] char exePath[PATH_MAX]; ^ /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] int ret; ^ /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] char fn[32]; ^ This seems to be related to the recent make changes 8339156: Use more fine-granular clang unused warnings https://bugs.openjdk.org/browse/JDK-8339156 (we use clang too on AIX) ------------- Commit messages: - JDK-8339364 Changes: https://git.openjdk.org/jdk/pull/20812/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339364 Stats: 61 lines in 14 files changed: 9 ins; 36 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/20812.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20812/head:pull/20812 PR: https://git.openjdk.org/jdk/pull/20812 From clanger at openjdk.org Mon Sep 2 12:20:20 2024 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 2 Sep 2024 12:20:20 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings In-Reply-To: References: Message-ID: <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com> On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) Looks good and seems like the warning helped to clean out coding in a few places. src/java.desktop/unix/native/common/awt/X11Color.c line 1236: > 1234: for (int i = 0; i < num_colors; i++) > 1235: alloc_col (awt_display, awtData->awt_cmap, red (rgbColors [i]), > 1236: green (rgbColors [i]), blue (rgbColors [i]), -1, Seems like indentation here could be improved a bit. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2275486151 PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1740824222 From ihse at openjdk.org Mon Sep 2 12:24:50 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 12:24:50 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 Message-ID: After JDK-8338404, the build produces warnings like: /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory Fix this by using a proper SetupExecute instead. ------------- Commit messages: - 8339371: jlink.log warning when building after JDK-8338404 Changes: https://git.openjdk.org/jdk/pull/20814/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339371 Stats: 17 lines in 1 file changed: 2 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20814/head:pull/20814 PR: https://git.openjdk.org/jdk/pull/20814 From ihse at openjdk.org Mon Sep 2 12:33:29 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 12:33:29 GMT Subject: RFR: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt Message-ID: >From the bug report: Users are reporting warnings like this: lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. ------------- Commit messages: - 8338916: Build warnings about overriding recipe for jvm-ldflags.txt Changes: https://git.openjdk.org/jdk/pull/20819/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20819&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338916 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20819.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20819/head:pull/20819 PR: https://git.openjdk.org/jdk/pull/20819 From jwaters at openjdk.org Mon Sep 2 12:36:20 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Sep 2024 12:36:20 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings In-Reply-To: References: Message-ID: <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com> On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) Ah, the joys of supporting a platform that isn't covered by the Actions compile and test safety net :) Looks Good, with that aside ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2275532558 From mbaesken at openjdk.org Mon Sep 2 12:36:20 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Sep 2024 12:36:20 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings In-Reply-To: <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com> References: <3fqsUh2hpNUSuZdV5ABE_B39ETgruLRO5jnEYzWAN18=.b8d42416-3e95-46ff-beac-545bad8207ef@github.com> Message-ID: On Mon, 2 Sep 2024 12:30:43 GMT, Julian Waters wrote: > Ah, the joys of supporting a platform that isn't covered by the Actions compile and test safety net :) A Linux/clang build in the GHA would have probably shown at least a part of those errors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324651948 From jwaters at openjdk.org Mon Sep 2 12:38:18 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Sep 2024 12:38:18 GMT Subject: RFR: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > Users are reporting warnings like this: > > lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > > I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. Looks trivial and good, but I can't quite tell if this introduces a new parameter to SetupNativeCompilation (It's been a while since I've worked on the JDK's build system). Does it? ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/20819#pullrequestreview-2275544664 From ihse at openjdk.org Mon Sep 2 12:38:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 12:38:19 GMT Subject: RFR: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > Users are reporting warnings like this: > > lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > > I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. No, it is a "local" variable. We use the `$1_` syntax to get namespaced variables. These can be used either as input (or output!) arguments to a function, or as internal helper variables. The one I added falls into the latter category. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20819#issuecomment-2324657733 From jwaters at openjdk.org Mon Sep 2 12:42:18 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Sep 2024 12:42:18 GMT Subject: RFR: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > Users are reporting warnings like this: > > lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > > I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. Alright, looks good in that case ------------- PR Comment: https://git.openjdk.org/jdk/pull/20819#issuecomment-2324666790 From mbaesken at openjdk.org Mon Sep 2 13:25:51 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Sep 2024 13:25:51 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust indentation in X11Color.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20812/files - new: https://git.openjdk.org/jdk/pull/20812/files/0fca9ee0..082e6f60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20812.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20812/head:pull/20812 PR: https://git.openjdk.org/jdk/pull/20812 From mbaesken at openjdk.org Mon Sep 2 13:25:51 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Sep 2024 13:25:51 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) macos-aarch64 failure seems to be https://bugs.openjdk.org/browse/JDK-8338712 (unrelated) Hi Christoph and Julian, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324745071 PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2324752339 From mbaesken at openjdk.org Mon Sep 2 13:25:51 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Sep 2024 13:25:51 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com> References: <21Qc2WxZ7rcyk2WSogCUe3L2ZMbctnz7QF7XdorWFn0=.6b90a395-9f9b-4408-a05f-abb0e5008b72@github.com> Message-ID: On Mon, 2 Sep 2024 12:17:57 GMT, Christoph Langer wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust indentation in X11Color.c > > src/java.desktop/unix/native/common/awt/X11Color.c line 1236: > >> 1234: for (int i = 0; i < num_colors; i++) >> 1235: alloc_col (awt_display, awtData->awt_cmap, red (rgbColors [i]), >> 1236: green (rgbColors [i]), blue (rgbColors [i]), -1, > > Seems like indentation here could be improved a bit. Agree, I adjust this in another commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1740919406 From alanb at openjdk.org Mon Sep 2 14:27:19 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 2 Sep 2024 14:27:19 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:20:24 GMT, Magnus Ihse Bursie wrote: > After JDK-8338404, the build produces warnings like: > > /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory > > Fix this by using a proper SetupExecute instead. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20814#pullrequestreview-2275782801 From dnsimon at openjdk.org Mon Sep 2 14:46:18 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 2 Sep 2024 14:46:18 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: <-E_SPEBIwKJIeGbguQqesZK2Dq6chOR5zM_NHc9lZ80=.58e76ebe-30fc-48af-8252-e01fc5d98a4d@github.com> References: <-E_SPEBIwKJIeGbguQqesZK2Dq6chOR5zM_NHc9lZ80=.58e76ebe-30fc-48af-8252-e01fc5d98a4d@github.com> Message-ID: <0VjlGQjFch8dAddLHynX_n8VeBSvfLT5LjpOczwJYvE=.bb6ffd6c-a4d8-4cf4-8f0f-b13349ed0948@github.com> On Mon, 2 Sep 2024 11:01:00 GMT, Magnus Ihse Bursie wrote: >> This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. >> This is a minimal smoke test to ensure these builds don't break. > > Also, you might not be aware of this, but I am working on a redesign of how static libraries are built in the JDK. This has been long overdue but have been put into sharp contrast by the Hermetic Java project. The long-term plan is to compile the .o files only onces, and then link them twice, once for normal dynamic libs, and once for static libs. This will make building static libs essentially free, and when that happens, enabling them on GHA is a no-brainer. > > It have only been making slow progress towards that goal due to a number of factors, so I cannot promise that it will done by any specific date, but it is a high priority task for me. > > So you can either try to argue that this should be enabled already, even though it costs extra cycles, or you can wait until the static libs redesign is done, and it will be enabled for free. Hi @magicus . Yes, I'm aware of your redesign of how static libraries are built in the JDK and am looking forward to it. I looked at the GHA usage summary for a number of OpenJDK PRs and see that the average compute time usage for all tests is about 26 hours ([example](https://github.com/lepestock/jdk/actions/runs/10662774885/usage)). Adding 10 extra mins doesn't seem like too much extra cost. As you say, static libs GHA testing will probably soon be enabled by default based on your current work in this area and will only get cheaper. Wrt to this PR, a secondary motivation is to allow for an external cron-like job to be able to automatically test OpenJDK PRs against libgraal (which needs the static libraries) without having to build the static-libs explicitly. Sure, it's a special case but is that so different from some of the existing jobs such as `linux-cross-compile / build (arm)` (~20 mins), `linux-x64-hs-zero / build (debug)` (~12 mins) and `linux-x64-hs-optimized / build (debug)` (~16 mins)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20803#issuecomment-2324908752 From mdoerr at openjdk.org Mon Sep 2 20:11:18 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 2 Sep 2024 20:11:18 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote: >> We get a couple of warnings as errors on AIX because of unused variables or functions , for example : >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] >> char exePath[PATH_MAX]; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] >> int ret; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] >> char fn[32]; >> ^ >> >> This seems to be related to the recent make changes >> 8339156: Use more fine-granular clang unused warnings >> https://bugs.openjdk.org/browse/JDK-8339156 >> (we use clang too on AIX) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust indentation in X11Color.c LGTM. Only minor nits. src/java.base/unix/native/libjava/TimeZone_md.c line 63: > 61: static const char *ETC_ENVIRONMENT_FILE = "/etc/environment"; > 62: #else > 63: static char *isFileIdentical(char* buf, size_t size, char *pathname); I think it should better be moved below `#if defined(__linux__) || defined(MACOSX)` instead of creating an else case. src/java.desktop/unix/native/common/awt/X11Color.c line 1234: > 1232: awt_allocate_systemrgbcolors (jint *rgbColors, int num_colors, > 1233: AwtGraphicsConfigDataPtr awtData) { > 1234: for (int i = 0; i < num_colors; i++) This requires C99. Is this ok for all platforms with all supported compilers? ------------- PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2276121217 PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741226250 PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741228253 From ihse at openjdk.org Mon Sep 2 22:35:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 22:35:19 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 20:06:06 GMT, Martin Doerr wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust indentation in X11Color.c > > src/java.desktop/unix/native/common/awt/X11Color.c line 1234: > >> 1232: awt_allocate_systemrgbcolors (jint *rgbColors, int num_colors, >> 1233: AwtGraphicsConfigDataPtr awtData) { >> 1234: for (int i = 0; i < num_colors; i++) > > This requires C99. Is this ok for all platforms with all supported compilers? Yes, we have C11 as minimum for the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741270798 From ihse at openjdk.org Mon Sep 2 22:35:20 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Sep 2024 22:35:20 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote: >> We get a couple of warnings as errors on AIX because of unused variables or functions , for example : >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] >> char exePath[PATH_MAX]; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] >> int ret; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] >> char fn[32]; >> ^ >> >> This seems to be related to the recent make changes >> 8339156: Use more fine-granular clang unused warnings >> https://bugs.openjdk.org/browse/JDK-8339156 >> (we use clang too on AIX) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust indentation in X11Color.c src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744: > 742: int rslt = pthread_attr_init(&attr); > 743: if (rslt != 0) return; > 744: pthread_create(&thr, &attr, SplashScreenThread, (void *) splash); You don't think it would be better to check the return code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741271285 From dholmes at openjdk.org Tue Sep 3 02:28:18 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Sep 2024 02:28:18 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 22:32:34 GMT, Magnus Ihse Bursie wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust indentation in X11Color.c > > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744: > >> 742: int rslt = pthread_attr_init(&attr); >> 743: if (rslt != 0) return; >> 744: pthread_create(&thr, &attr, SplashScreenThread, (void *) splash); > > You don't think it would be better to check the return code? This code is devoid of pretty much all error handling and logging, but I agree that a simple fprintf on error would be useful. Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741354811 From ihse at openjdk.org Tue Sep 3 05:55:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 05:55:18 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com> On Tue, 3 Sep 2024 02:25:16 GMT, David Holmes wrote: > Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one? Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-)) I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741464573 From dholmes at openjdk.org Tue Sep 3 06:18:18 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 3 Sep 2024 06:18:18 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com> References: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com> Message-ID: On Tue, 3 Sep 2024 05:52:31 GMT, Magnus Ihse Bursie wrote: >> This code is devoid of pretty much all error handling and logging, but I agree that a simple fprintf on error would be useful. >> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one? > >> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one? > > Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-)) > > I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not. At one stage we started using the idiom: (void) someFunc(); to tell the compiler to not warn about the unused result. IIRC that stopped working. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741484485 From jwaters at openjdk.org Tue Sep 3 06:45:18 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 3 Sep 2024 06:45:18 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com> Message-ID: On Tue, 3 Sep 2024 06:16:06 GMT, David Holmes wrote: >>> Also doesn't a call like this trigger the warning about ignoring a function result, or have we disabled that one? >> >> Such a warning would be horrible to have enable. Then you would have to read the value of every function that thought it should return a value, even if it was just intended as some additional information that perhaps not everyone wanted to use. (And then you could not just store it into a variable and ignore it, since that would trigger the "unused variable" warning! ;-)) >> >> I know IntelliJ can provide warnings when ignoring the return value of a few select JDK methods that are often used incorrectly, but then they had to annotate these specially. I don't know if there is any similar kind of annotation for clang/gcc that can warn about ignoring return values that really, really shouldn't be ignored, but I'd guess not. > > At one stage we started using the idiom: > > (void) someFunc(); > > to tell the compiler to not warn about the unused result. IIRC that stopped working. Not entirely sure about clang, but casting to void to silence warnings should still work for gcc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741510831 From mbaesken at openjdk.org Tue Sep 3 07:13:19 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Sep 2024 07:13:19 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: <1YazhBzFJBBSy6KnqHuWOBFYfBQgx2ObU5WNlgb97J8=.8015a1da-4780-4738-88fd-886b75bee195@github.com> Message-ID: On Tue, 3 Sep 2024 06:42:42 GMT, Julian Waters wrote: >> At one stage we started using the idiom: >> >> (void) someFunc(); >> >> to tell the compiler to not warn about the unused result. IIRC that stopped working. > > Not entirely sure about clang, but casting to void to silence warnings should still work for gcc > You don't think it would be better to check the return code? Hi , maybe we could check it ; in HS code we mostly do (but there we have UL). But would be a separate PR I guess (splashscreen_sys.m on macOS has the same issue) . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20812#discussion_r1741542559 From mbaesken at openjdk.org Tue Sep 3 07:26:53 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Sep 2024 07:26:53 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v3] In-Reply-To: References: Message-ID: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: TimeZone_md move platform stuff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20812/files - new: https://git.openjdk.org/jdk/pull/20812/files/082e6f60..e20948ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20812&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20812.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20812/head:pull/20812 PR: https://git.openjdk.org/jdk/pull/20812 From mbaesken at openjdk.org Tue Sep 3 07:26:53 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Sep 2024 07:26:53 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v2] In-Reply-To: References: Message-ID: <0_Av5QvMB9nUSbRIN-x2Z6OhkN__s0pzRSKw-8kEGLg=.7e4115e6-2f3a-4270-8fd7-f85ea8b2c137@github.com> On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote: >> We get a couple of warnings as errors on AIX because of unused variables or functions , for example : >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] >> char exePath[PATH_MAX]; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] >> int ret; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] >> char fn[32]; >> ^ >> >> This seems to be related to the recent make changes >> 8339156: Use more fine-granular clang unused warnings >> https://bugs.openjdk.org/browse/JDK-8339156 >> (we use clang too on AIX) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust indentation in X11Color.c I would suggest creating a JBS issue and later PR for the pthread_create return code checking (both unix and macos). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2325785214 From fgao at openjdk.org Tue Sep 3 08:36:23 2024 From: fgao at openjdk.org (Fei Gao) Date: Tue, 3 Sep 2024 08:36:23 GMT Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime part [v3] In-Reply-To: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com> References: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com> Message-ID: On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote: >> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform. >> >> Motivation >> >> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1]. >> >> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3]. >> >> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits: >> >> >> GNU_PROPERTY_AARCH64_FEATURE_1_BTI >> GNU_PROPERTY_AARCH64_FEATURE_1_PAC >> >> >> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled. >> >> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not. >> >> Goal >> >> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so. >> >> Implementation >> >> Task-1: find out the problematic input objects >> >> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so. >> >> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list: >> >> >> src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S >> >> >> Task-2: add `.note.gnu.property` section for these assembly files >> >> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed. >> >> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i... > > Fei Gao 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: > > - Fix indentation > - Merge branch 'master' into enable-bti-runtime > - Clean up makefile > - Merge branch 'master' into enable-bti-runtime > - 8337536: AArch64: Enable BTI branch protection for runtime part > > This patch enables BTI branch protection for runtime part on > Linux/aarch64 platform. > > Motivation > > 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. > User-level packages can gain additional hardening by compiling with the > GCC/Clang flag `-mbranch-protection=flag`. See [1]. > > 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as > one VM configure flag, which would pass `-mbranch-protection=standard` > compilation flags to all c/c++ files. Note that `standard` turns on both > `pac-ret` and `bti` branch protections. For more details about code > reuse attacks and hardware-assisted branch protections on AArch64, see > [3]. > > However, we checked the `.note.gnu.property` section of all the shared > libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so > didn't set these two target feature bits: > > ``` > GNU_PROPERTY_AARCH64_FEATURE_1_BTI > GNU_PROPERTY_AARCH64_FEATURE_1_PAC > ``` > > Note-1: BTI is an all or nothing property for a link unit [4]. That is, > libjvm.so is not BTI-enabled. > > Note-2: PAC bit in `.note.gnu.property` section is used to protect > `.got.plt` table. It's independent of whether the relocatable objects > use PAC or not. > > Goal > > Hence, this patch aims to set PAC/BTI feature bits of the > `.note.gnu.property` section for libjvm.so. > > Implementation > > Task-1: find out the problematic input objects > > From [5], "Static linkers processing ELF relocatable objects must set > the feature bit in the output object or image only if all the input > objects have the corresponding feature bit set." Hence we suspect that > the root cause is probably that the PAC/BTI feature bits are not set > only for some input objects of libjvm.so. > > In order to find out these inputs, we passed `--force-bti` linker flag > [4] in my local test. This linker flag would warn if any input object > does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following > list: > > ... Can I have a review please? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2325917997 From aph at openjdk.org Tue Sep 3 09:28:22 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 3 Sep 2024 09:28:22 GMT Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime part [v3] In-Reply-To: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com> References: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com> Message-ID: On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao wrote: >> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform. >> >> Motivation >> >> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1]. >> >> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3]. >> >> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits: >> >> >> GNU_PROPERTY_AARCH64_FEATURE_1_BTI >> GNU_PROPERTY_AARCH64_FEATURE_1_PAC >> >> >> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled. >> >> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not. >> >> Goal >> >> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so. >> >> Implementation >> >> Task-1: find out the problematic input objects >> >> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so. >> >> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list: >> >> >> src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S >> src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S >> >> >> Task-2: add `.note.gnu.property` section for these assembly files >> >> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed. >> >> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i... > > Fei Gao 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: > > - Fix indentation > - Merge branch 'master' into enable-bti-runtime > - Clean up makefile > - Merge branch 'master' into enable-bti-runtime > - 8337536: AArch64: Enable BTI branch protection for runtime part > > This patch enables BTI branch protection for runtime part on > Linux/aarch64 platform. > > Motivation > > 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. > User-level packages can gain additional hardening by compiling with the > GCC/Clang flag `-mbranch-protection=flag`. See [1]. > > 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as > one VM configure flag, which would pass `-mbranch-protection=standard` > compilation flags to all c/c++ files. Note that `standard` turns on both > `pac-ret` and `bti` branch protections. For more details about code > reuse attacks and hardware-assisted branch protections on AArch64, see > [3]. > > However, we checked the `.note.gnu.property` section of all the shared > libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so > didn't set these two target feature bits: > > ``` > GNU_PROPERTY_AARCH64_FEATURE_1_BTI > GNU_PROPERTY_AARCH64_FEATURE_1_PAC > ``` > > Note-1: BTI is an all or nothing property for a link unit [4]. That is, > libjvm.so is not BTI-enabled. > > Note-2: PAC bit in `.note.gnu.property` section is used to protect > `.got.plt` table. It's independent of whether the relocatable objects > use PAC or not. > > Goal > > Hence, this patch aims to set PAC/BTI feature bits of the > `.note.gnu.property` section for libjvm.so. > > Implementation > > Task-1: find out the problematic input objects > > From [5], "Static linkers processing ELF relocatable objects must set > the feature bit in the output object or image only if all the input > objects have the corresponding feature bit set." Hence we suspect that > the root cause is probably that the PAC/BTI feature bits are not set > only for some input objects of libjvm.so. > > In order to find out these inputs, we passed `--force-bti` linker flag > [4] in my local test. This linker flag would warn if any input object > does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following > list: > > ... What is the effect on JNI? Is there full interworking with non-branch-protected libraries? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2326037813 From mdoerr at openjdk.org Tue Sep 3 09:33:20 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 3 Sep 2024 09:33:20 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v3] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote: >> We get a couple of warnings as errors on AIX because of unused variables or functions , for example : >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] >> char exePath[PATH_MAX]; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] >> int ret; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] >> char fn[32]; >> ^ >> >> This seems to be related to the recent make changes >> 8339156: Use more fine-granular clang unused warnings >> https://bugs.openjdk.org/browse/JDK-8339156 >> (we use clang too on AIX) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > TimeZone_md move platform stuff Thanks for the update! I also think that adding result checks is better in a separate RFE. This build fix is good to go IMHO. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20812#pullrequestreview-2276906529 From mbaesken at openjdk.org Tue Sep 3 12:05:25 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Sep 2024 12:05:25 GMT Subject: Integrated: 8339364: AIX build fails: various unused variable and function warnings In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote: > We get a couple of warnings as errors on AIX because of unused variables or functions , for example : > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] > char exePath[PATH_MAX]; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] > int ret; > ^ > /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] > char fn[32]; > ^ > > This seems to be related to the recent make changes > 8339156: Use more fine-granular clang unused warnings > https://bugs.openjdk.org/browse/JDK-8339156 > (we use clang too on AIX) This pull request has now been integrated. Changeset: 8ea6adc6 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8ea6adc623ca2183046d794eba806065deea916e Stats: 65 lines in 14 files changed: 9 ins; 40 del; 16 mod 8339364: AIX build fails: various unused variable and function warnings Reviewed-by: mdoerr, clanger, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/20812 From mbaesken at openjdk.org Tue Sep 3 12:09:23 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 3 Sep 2024 12:09:23 GMT Subject: RFR: 8339364: AIX build fails: various unused variable and function warnings [v3] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote: >> We get a couple of warnings as errors on AIX because of unused variables or functions , for example : >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10: error: unused variable 'exePath' [-Werror,-Wunused-variable] >> char exePath[PATH_MAX]; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:668:9: error: unused variable 'ret' [-Werror,-Wunused-variable] >> int ret; >> ^ >> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:664:10: error: unused variable 'fn' [-Werror,-Wunused-variable] >> char fn[32]; >> ^ >> >> This seems to be related to the recent make changes >> 8339156: Use more fine-granular clang unused warnings >> https://bugs.openjdk.org/browse/JDK-8339156 >> (we use clang too on AIX) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > TimeZone_md move platform stuff I created https://bugs.openjdk.org/browse/JDK-8339475 for the pthread_create return code checking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20812#issuecomment-2326356942 From ihse at openjdk.org Tue Sep 3 13:02:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 13:02:55 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher Message-ID: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). ------------- Commit messages: - Makefile changes needed for static-launcher and static-jdk-image targets - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339480 Stats: 429 lines in 22 files changed: 351 ins; 5 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Tue Sep 3 13:02:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 13:02:55 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). @jianglizhou Can you please check if there are any other contributors that should be acknowledged? The `static-jdk` image is enough to run a simple HelloWorld java program; however it cannot yet run JTReg tests. The reason for this is, afaict, that the javac launcher is missing. I am planning to examine if it is possible to add a small shim `javac` launcher that calls the static `java` with the proper main class. (And similarly for the other launchers.) The goal here must, after all, be that we should be able to run the normal jtreg tests on the `static-jdk` image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2326445877 PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2326452510 From magnus.ihse.bursie at oracle.com Tue Sep 3 13:08:14 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 15:08:14 +0200 Subject: PR with static-jdk launcher Message-ID: <525ef7ed-fba6-4a7a-9257-ec101a9afa00@oracle.com> Hi, I just wanted to let you know that there is now a PR with an initial implementation of a static java launcher: https://github.com/openjdk/jdk/pull/20837 Some noteworthy limitations: 1) Support for hiding local symbols in static libraries are not yet implemented. This mean that there are symbol clashes between some libraries. As a result, I have temporarily disabled a few libraries. This in turn means that the native code is not complete, so not all JDK functionality is present. How much is missing depends on which platform you run. 2) Only the java launcher is present, no other JDK launchers (including javac) are present. This means that it is not possible to run JTReg tests. I have an idea on how to address this in the future. 3) On Windows, changes need to be done in the launcher code; similar to what has been done for Linux and macOS. As a result of this, the static launcher builds just fine, but crashes at startup. I don't think it is hard to fix, but I have not prioritized this. The reason is that the inclusion of a working static launcher for macOS and Linux will help the Hermetic Java project along, and the Windows launcher can be fixed in the meantime. 4) This is not tested on AIX nor any other platforms apart from Linux, macOS and Windows. It is tested with both gcc and clang on Linux. 5) There are still a lot of untidy and badly structured code surrounding static libraries. I hope to address some of this mess as follow-up work. 6) This PR does not address the issue that all native files are compiled twice. That is a completely orthogonal problem to this. /Magnus From erikj at openjdk.org Tue Sep 3 13:29:20 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 13:29:20 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 21:35:02 GMT, Magnus Ihse Bursie wrote: >> The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html. >> >> Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated. >> >> The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. >> >> I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix bad change in BuildMicrobenchmarks Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20798#pullrequestreview-2277445194 From erikj at openjdk.org Tue Sep 3 13:29:20 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 13:29:20 GMT Subject: RFR: 8339336: Fix build system whitespace to adhere to coding conventions [v2] In-Reply-To: References: Message-ID: <7Z98Ei-DMo4R9HX4ZHo-Fe8mmJ59wdmtk81DvPm8jaU=.91a188be-7d31-4701-b9d8-992fbf62f75d@github.com> On Mon, 2 Sep 2024 08:59:05 GMT, Magnus Ihse Bursie wrote: > I've done that now, and it looks clean on all platforms. (With one exception: we include the vardeps files for jar files in jdk/demos -- historical reasons, I assume -- and they look slightly different; but they should not really have been included in the comparison anyway so it does not matter.) That sounds like a relatively recent bug, as the vardeps files are relatively recent (in the context of building demos at least), again not something to fix in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20798#issuecomment-2326526244 From erikj at openjdk.org Tue Sep 3 13:32:19 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 13:32:19 GMT Subject: RFR: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt In-Reply-To: References: Message-ID: <-nCGaZ92HjRsyijt9Fq1Z7Uzxj3MGWbuIkD6-Ysz9Pg=.4adbf01d-8e81-4268-8fb7-e59dbd8b2e26@github.com> On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > Users are reporting warnings like this: > > lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > > I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20819#pullrequestreview-2277451125 From ihse at openjdk.org Tue Sep 3 15:34:28 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 15:34:28 GMT Subject: Integrated: 8338916: Build warnings about overriding recipe for jvm-ldflags.txt In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:28:17 GMT, Magnus Ihse Bursie wrote: > From the bug report: > > Users are reporting warnings like this: > > lib/CompileGtest.gmk:84: warning: overriding recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > lib/CompileJvm.gmk:166: warning: ignoring old recipe for target '/.../build/linux-x64/make-support/compile-commands/jvm-ldflags.txt' > > I believe this is caused by [JDK-8338290](https://bugs.openjdk.org/browse/JDK-8338290), where the jvm-ldflags.txt target file isn't made unique enough. This pull request has now been integrated. Changeset: c3adcb84 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/c3adcb843953b599b3c93d6b51afcc709ceaf45b Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8338916: Build warnings about overriding recipe for jvm-ldflags.txt Reviewed-by: jwaters, erikj ------------- PR: https://git.openjdk.org/jdk/pull/20819 From ihse at openjdk.org Tue Sep 3 15:34:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 15:34:30 GMT Subject: Integrated: 8339336: Fix build system whitespace to adhere to coding conventions In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 16:27:18 GMT, Magnus Ihse Bursie wrote: > The build system code has unfortunately diverted in some places from the conventions as described in https://openjdk.org/groups/build/doc/code-conventions.html. > > Instead of trying to fix these when touching code nearby, I'd like to make an effort to fix all issues at once and separately. Incremental fixes has their benefit, but they can also muddy the actual fix and are not always appreciated. > > The updates in this patch have all been discovered using automated tools, but each and every change has been manually scrutinized. Those that the automatic tools pointed out that, but that were not obviously or clear-cut safe (e.g. adding spaces after comma, in `subst` or similar situations) were reverted before I pushed. I chose to err on the "First, do no harm" side, so there might be places that could have been corrected, but were not. > > I have made a single type of change per commit in this branch. It might be easier to review this by looking at one commit at a time. This pull request has now been integrated. Changeset: 66945e50 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/66945e501049de3a1e1d73303928af87190ae33c Stats: 634 lines in 81 files changed: 27 ins; 10 del; 597 mod 8339336: Fix build system whitespace to adhere to coding conventions Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/20798 From sgehwolf at openjdk.org Tue Sep 3 16:10:57 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 3 Sep 2024 16:10:57 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v36] In-Reply-To: References: Message-ID: <0EvV9kxXGl1wYfhaxqwiUs7rImD9AvXIi-o4Rnq20t8=.67c5f7d9-2890-4c5b-8368-20252562bceb@github.com> > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b eing modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 141 commits: - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - JLinkDedupTestBatchSizeOne.java test fix Run only the packaged modules version if we have a linkable JDK runtime with packaged modules available as well in the JDK install. - Enable IncludeLocalesPluginTest - Enable GenerateJLIClassesPluginTest.java test - Enable JLinkReproducibleTest.java for linkable JDK images - Remove restriction on directory based modules Enable the following tests: - JLink100Modules.java - JLinkDedupTestBatchSizeOne.java - Comment fix in JRTArchive. Long line in JlinkTask - ... and 131 more: https://git.openjdk.org/jdk/compare/0d593cd1...ec68b0a8 ------------- Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=35 Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From erikj at openjdk.org Tue Sep 3 16:13:23 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 16:13:23 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:20:24 GMT, Magnus Ihse Bursie wrote: > After JDK-8338404, the build produces warnings like: > > /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory > > Fix this by using a proper SetupExecute instead. Marked as reviewed by erikj (Reviewer). make/InterimImage.gmk line 51: > 49: OUTPUT_DIR := $(INTERIM_IMAGE_DIR), \ > 50: SUPPORT_DIR := $(INTERIM_JLINK_SUPPORT_DIR), \ > 51: COMMAND := $(RM) -r $(INTERIM_IMAGE_DIR) && $(JLINK_TOOL) --output $(INTERIM_IMAGE_DIR) \ In Images.gmk, we use the `PRE_COMMAND` option for running `rm`. Maybe you want to use the same pattern here? ------------- PR Review: https://git.openjdk.org/jdk/pull/20814#pullrequestreview-2277895103 PR Review Comment: https://git.openjdk.org/jdk/pull/20814#discussion_r1742330874 From erikj at openjdk.org Tue Sep 3 16:18:23 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 16:18:23 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote: > This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. > This is a minimal smoke test to ensure these builds don't break. I think adding static libs to one platform and flavor combination seems reasonable for now. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20803#pullrequestreview-2277906746 From ihse at openjdk.org Tue Sep 3 17:43:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 17:43:23 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: <6sINfMbHvd8rx-D1Urw4cKKHw1QAUY3PCSByPyCZwqs=.ce6f1014-bc89-43b3-8674-d0c3bbc01f9d@github.com> On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote: > This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. > This is a minimal smoke test to ensure these builds don't break. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20803#pullrequestreview-2278079954 From ihse at openjdk.org Tue Sep 3 17:43:38 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 17:43:38 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 [v2] In-Reply-To: References: Message-ID: > After JDK-8338404, the build produces warnings like: > > /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory > > Fix this by using a proper SetupExecute instead. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use PRE_COMMAND instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20814/files - new: https://git.openjdk.org/jdk/pull/20814/files/725a74ff..a2e64ed0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20814&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20814&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20814/head:pull/20814 PR: https://git.openjdk.org/jdk/pull/20814 From ihse at openjdk.org Tue Sep 3 17:43:38 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 17:43:38 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 [v2] In-Reply-To: References: Message-ID: <3tAe0scLxfIWYt3gvUAvB9YXi-U9bW14HXMAopbv9_E=.ee431234-1707-4d95-b92a-e161dfc362f2@github.com> On Tue, 3 Sep 2024 16:10:23 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Use PRE_COMMAND instead > > make/InterimImage.gmk line 51: > >> 49: OUTPUT_DIR := $(INTERIM_IMAGE_DIR), \ >> 50: SUPPORT_DIR := $(INTERIM_JLINK_SUPPORT_DIR), \ >> 51: COMMAND := $(RM) -r $(INTERIM_IMAGE_DIR) && $(JLINK_TOOL) --output $(INTERIM_IMAGE_DIR) \ > > In Images.gmk, we use the `PRE_COMMAND` option for running `rm`. Maybe you want to use the same pattern here? That's a good suggestion. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20814#discussion_r1742441334 From erikj at openjdk.org Tue Sep 3 18:12:22 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 18:12:22 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). I tried to take this for a spin on my m1 mac laptop. I ran configure and then `make static-jdk-image`. The build failed with the following: chmod: /Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib: No such file or directory ModuleWrapper.gmk:81: recipe for target '/Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib' failed make[3]: *** [/Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib] Error 1 make[3]: *** Waiting for unfinished jobs.... make/Main.gmk:191: recipe for target 'java.base-libs' failed make[2]: *** [java.base-libs] Error 2 I'm guessing this would work if I built the regular image first, or at least at the same time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327132241 From dnsimon at openjdk.org Tue Sep 3 19:04:27 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 3 Sep 2024 19:04:27 GMT Subject: RFR: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: <5q79rJj4fpkBSvT6djfMJmM-c8WgB9QvSJzUrSjh3FE=.91ca122b-6c7f-470f-a1ef-90c79b3f566c@github.com> On Tue, 3 Sep 2024 16:15:33 GMT, Erik Joelsson wrote: >> This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. >> This is a minimal smoke test to ensure these builds don't break. > > I think adding static libs to one platform and flavor combination seems reasonable for now. Thanks for the reviews @erikj79 and @magicus . ------------- PR Comment: https://git.openjdk.org/jdk/pull/20803#issuecomment-2327216597 From dnsimon at openjdk.org Tue Sep 3 19:07:26 2024 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 3 Sep 2024 19:07:26 GMT Subject: Integrated: 8337265: Test static-libs build in GitHub Actions In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 06:37:26 GMT, Doug Simon wrote: > This PR modifies the GitHub Actions product build on Linux to include building of the static-libs bundle. > This is a minimal smoke test to ensure these builds don't break. This pull request has now been integrated. Changeset: 130ac13c Author: Doug Simon URL: https://git.openjdk.org/jdk/commit/130ac13cb9c2dede4ceede4ad6c3c820fdea2fe3 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod 8337265: Test static-libs build in GitHub Actions Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/20803 From ihse at openjdk.org Tue Sep 3 19:53:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 19:53:18 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <1nXZ6wL05zwQD3alCwKAo7P0XbkXkJbX_p5TFTXobvI=.d119ebf5-f5b0-495b-a16b-259110b13357@github.com> On Tue, 3 Sep 2024 18:10:06 GMT, Erik Joelsson wrote: > I'm guessing this would work if I built the regular image first, or at least at the same time. No, I don't think that should matter. `static-jdk-image` depends on `exploded-image`, and the files in your error message resides in `jdk`, not `images/jdk`. I have never seen this problem before. I'm not even sure why or when we try to chmod libjsig? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327308045 From ihse at openjdk.org Tue Sep 3 19:53:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Sep 2024 19:53:19 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). I wonder if it is related to JDK-8336498? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2327311982 From erikj at openjdk.org Tue Sep 3 20:01:21 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 20:01:21 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). make/ModuleWrapper.gmk line 59: > 57: endif > 58: endif > 59: This part looks a bit convoluted. It would be nice with a comment explaining what it does, where `$($(MODULE)_JDK_LIBS)` is coming from and what consumes the module-libs.txt. make/StaticLibs.gmk line 171: > 169: > 170: $(eval $(call SetupCopyFiles, copy-static-launcher, \ > 171: SRC := $(dir $(JAVA_LAUNCHER)), \ If only copying a single file, this becomes the default value for SRC, so no need to specify it. make/common/JdkNativeCompilation.gmk line 310: > 308: $$(MODULE)_JDK_LIBS += $$($1_NAME) > 309: endif > 310: endif Same, here as in ModuleWrapper.gmk, I think we need a comment explaining how this is consumed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742601500 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742500522 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1742605313 From erikj at openjdk.org Tue Sep 3 20:03:20 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Sep 2024 20:03:20 GMT Subject: RFR: 8339371: jlink.log warning when building after JDK-8338404 [v2] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 17:43:38 GMT, Magnus Ihse Bursie wrote: >> After JDK-8338404, the build produces warnings like: >> >> /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory >> >> Fix this by using a proper SetupExecute instead. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use PRE_COMMAND instead Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20814#pullrequestreview-2278371617 From ihse at openjdk.org Wed Sep 4 10:37:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Sep 2024 10:37:24 GMT Subject: Integrated: 8339371: jlink.log warning when building after JDK-8338404 In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:20:24 GMT, Magnus Ihse Bursie wrote: > After JDK-8338404, the build produces warnings like: > > /bin/tee: /localhome/git/jdk-CDR/build/linux-x64/support/interim-image/jlink.log: No such file or directory > > Fix this by using a proper SetupExecute instead. This pull request has now been integrated. Changeset: 4e2dde2f Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4e2dde2f0d6f96d5f07020d2417189f411c4596a Stats: 17 lines in 1 file changed: 2 ins; 2 del; 13 mod 8339371: jlink.log warning when building after JDK-8338404 Reviewed-by: erikj, alanb ------------- PR: https://git.openjdk.org/jdk/pull/20814 From fgao at openjdk.org Wed Sep 4 13:05:20 2024 From: fgao at openjdk.org (Fei Gao) Date: Wed, 4 Sep 2024 13:05:20 GMT Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime part [v3] In-Reply-To: References: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com> Message-ID: On Tue, 3 Sep 2024 09:25:55 GMT, Andrew Haley wrote: > What is the effect on JNI? Is there full interworking with non-branch-protected libraries? @theRealAph, thanks for your review! It should be no problem to have libjvm.so built with BTI and a JNI library built without BTI. BTI marks code pages as "Guarded". For executable pages that have been guarded, all indirect branches must have a destination that is a BTI instruction of the appropriate type. But for unguarded pages, we don?t do this check. This allows BTI to be incrementally turned on for a specific codebase. BTI would then protect the branches within the libraries with BTI but not those without BTI. When we're jumping from JNI to libjvm, it's OK because BTI is enabled for libjvm.so and all the entry points have landing pads. When we're jumping from libjvm to JNI, it's also OK because the code cache pages have BTI disabled so it doesn't need landing pads. To verify it, after patching this PR, I disabled the `-mbranch-protection=standard` flag for all other libraries and enabled it only for jvm, we can have libjvm.so built with BTI and all other libraries built without BTI. Jtreg tests passed. Before the patch, on mainline, we have all other libraries built with BTI but libjvm.so built without BTI, we also have no BTI failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2328972872 From fyang at openjdk.org Wed Sep 4 15:18:43 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 4 Sep 2024 15:18:43 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap Message-ID: Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. [1] https://snapshot.debian.org/ [2] https://lists.debian.org/debian-snapshot/ Testing: - [ ] GHA ------------- Commit messages: - 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap Changes: https://git.openjdk.org/jdk/pull/20853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20853&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339548 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20853/head:pull/20853 PR: https://git.openjdk.org/jdk/pull/20853 From fyang at openjdk.org Wed Sep 4 15:18:43 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 4 Sep 2024 15:18:43 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [ ] GHA @shipilev @erikj79 : Please take a look. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20853#issuecomment-2329324518 From shade at openjdk.org Wed Sep 4 15:32:20 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 4 Sep 2024 15:32:20 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [ ] GHA I don't mind doing this, especially given that RISC-V job would "pass" cleanly if this snapshot does not work. It is on you to make sure it does work :) ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20853#pullrequestreview-2280576238 From jiangli at openjdk.org Wed Sep 4 23:39:54 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 4 Sep 2024 23:39:54 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). make/StaticLibs.gmk line 1: > 1: # Perhaps also consider adopting StaticLink.gmk file name from the https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, as we are mostly doing the static linking here. Creating the static libs is handled elsewhere. make/StaticLibs.gmk line 71: > 69: # libsspi_bridge has name conflicts with sunmscapi > 70: BROKEN_STATIC_LIBS += sspi_bridge > 71: # These libs define DllMain which conflict with Hotspot I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch. make/StaticLibs.gmk line 74: > 72: BROKEN_STATIC_LIBS += awt dt_shmem dt_socket javaaccessbridge > 73: # These libs are dependent on any of the above disabled libs > 74: BROKEN_STATIC_LIBS += fontmanager jawt lcms net nio Which specific dependent cause these libs being excluded? In https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, these JDK libs (except `libjawt.a`) are statically linked into `javastatic`. make/StaticLibs.gmk line 118: > 116: OPTIMIZATION := HIGH, \ > 117: STATIC_LAUNCHER := true, \ > 118: LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \ I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined. On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923. make/modules/java.desktop/lib/AwtLibraries.gmk line 176: > 174: > 175: ifneq ($(ENABLE_HEADLESS_ONLY), true) > 176: # We cannot link with both awt_headless and awt_xawt at the same time Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java. src/java.base/unix/native/libjli/java_md.c line 300: > 298: char jvmcfg[], jint so_jvmcfg) { > 299: /* Compute/set the name of the executable. This is needed for macOS. */ > 300: SetExecname(*pargv); Why is `SetExecname()` needed for the static case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744614583 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744604685 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744603414 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744611776 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744616878 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744620611 From jiangli at openjdk.org Thu Sep 5 00:05:50 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 00:05:50 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). src/hotspot/share/classfile/classLoader.cpp line 953: > 951: assert(CanonicalizeEntry == nullptr, "should not load java library twice"); > 952: if (is_vm_statically_linked()) { > 953: CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, os::lookup_function("JDK_Canonicalize")); Can you add an assert to make sure `CanonicalizeEntry` is not NULL? src/hotspot/share/classfile/classLoader.cpp line 969: > 967: > 968: if (is_vm_statically_linked()) { > 969: JImageOpen = CAST_TO_FN_PTR(JImageOpen_t, os::lookup_function("JIMAGE_Open")); It might be good to assert these are not NULL as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744635408 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744635916 From jiangli at openjdk.org Thu Sep 5 00:17:51 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 00:17:51 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). src/java.base/unix/native/libjli/java_md.c line 509: > 507: > 508: if (GetApplicationHome(path, pathsize)) { > 509: if (JLI_IsStaticallyLinked()) { `GetJREPath()` does not need to be called for the static case. Any reason why this path is executed for static mode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744642315 From jiangli at openjdk.org Thu Sep 5 00:27:50 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 00:27:50 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <4ZyGLLJL7fVUDI0QXFBOZ1dK97dOjWKDuDCBhsPqEHs=.ac87ad4f-0839-4d5d-a59e-b273f37a6711@github.com> On Tue, 3 Sep 2024 12:51:13 GMT, Magnus Ihse Bursie wrote: > @jianglizhou Can you please check if there are any other contributors that should be acknowledged? Thanks for asking! I checked all the related changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. Following are the related commits from the branch corresponding to the extracted changes included in this PR. There are no other author for those changes. However, all changes have go though prior reviews by my teammates. I didn't ask it for the earlier integration PR, is there way to mention the reviewer contributions? - https://github.com/openjdk/leyden/commit/bceb753f79b4bc767fdfb71d5f68a84430644df6 - https://github.com/openjdk/leyden/commit/a998a9d6ca44a93d4e9859a17de2dca60963de76 - https://github.com/openjdk/leyden/commit/53aa8f0cf418ab5f435a4b9996c7754fb8505d4b - https://github.com/openjdk/leyden/commit/63f84f5c0a98077c8f49a19f026f103b9e29d6e0 - https://github.com/openjdk/leyden/commit/afe9ca06dd86e8983768de80ba1a08f3c68589b4 - https://github.com/openjdk/leyden/commit/7d75a7f4d6aa020b7580fbbf660b2b3e3a41b27 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2330368791 From fyang at openjdk.org Thu Sep 5 01:27:51 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 5 Sep 2024 01:27:51 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [x] GHA OK. Great. I see GHAs (especially linux-cross-compile for riscv64 job) are clean with this change. I will integrate after I get a second review from build/GHA maintainers. Maybe @erikj79 ? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20853#issuecomment-2330420516 From jwaters at openjdk.org Thu Sep 5 05:11:55 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 5 Sep 2024 05:11:55 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Wed, 4 Sep 2024 23:06:00 GMT, Jiangli Zhou wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > make/StaticLibs.gmk line 71: > >> 69: # libsspi_bridge has name conflicts with sunmscapi >> 70: BROKEN_STATIC_LIBS += sspi_bridge >> 71: # These libs define DllMain which conflict with Hotspot > > I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch. DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMain when compiling them as static libraries > src/hotspot/share/classfile/classLoader.cpp line 953: > >> 951: assert(CanonicalizeEntry == nullptr, "should not load java library twice"); >> 952: if (is_vm_statically_linked()) { >> 953: CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, os::lookup_function("JDK_Canonicalize")); > > Can you add an assert to make sure `CanonicalizeEntry` is not NULL? Also please remember to use nullptr and not NULL! @kimbarrett would appreciate it :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744808169 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744810286 From ihse at openjdk.org Thu Sep 5 09:54:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Sep 2024 09:54:52 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters wrote: >> make/StaticLibs.gmk line 71: >> >>> 69: # libsspi_bridge has name conflicts with sunmscapi >>> 70: BROKEN_STATIC_LIBS += sspi_bridge >>> 71: # These libs define DllMain which conflict with Hotspot >> >> I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch. > > DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMai n when compiling them as static libraries As Julian says, this is for Windows, and you have not even tried to compile that in your prototype. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745162496 From ihse at openjdk.org Thu Sep 5 09:54:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Sep 2024 09:54:53 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com> On Wed, 4 Sep 2024 23:03:23 GMT, Jiangli Zhou wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > make/StaticLibs.gmk line 74: > >> 72: BROKEN_STATIC_LIBS += awt dt_shmem dt_socket javaaccessbridge >> 73: # These libs are dependent on any of the above disabled libs >> 74: BROKEN_STATIC_LIBS += fontmanager jawt lcms net nio > > Which specific dependent cause these libs being excluded? In https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, these JDK libs (except `libjawt.a`) are statically linked into `javastatic`. Well, but your proof-of-concept only supports clang on linux, where you have enabled symbol hiding. Our conclusion in the zoom talks was that we should strive for getting a static launcher build pushed into mainline before we have full and proper support for symbol hiding on all platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745161079 From ihse at openjdk.org Thu Sep 5 10:02:58 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Sep 2024 10:02:58 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). The `/contributor` is supposed to add attribution to whomever wrote the code. There is no way to document any prior reviewing for code; but they are of course welcome to review this PR, and then it will be documented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2331113024 From ihse at openjdk.org Thu Sep 5 10:02:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Sep 2024 10:02:59 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Wed, 4 Sep 2024 23:28:10 GMT, Jiangli Zhou wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > make/modules/java.desktop/lib/AwtLibraries.gmk line 176: > >> 174: >> 175: ifneq ($(ENABLE_HEADLESS_ONLY), true) >> 176: # We cannot link with both awt_headless and awt_xawt at the same time > > Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java. That would require quite some work then..! The two libraries are meant as exclusive complements to each other -- they both implement the same "entry points", but in different ways -- one with X11 support, and one without. For other reasons (outside of static launcher reasons) I'd like to see some refactoring in how this is implemented, but that is completely outside this discussion. For the static launcher scenario, I can't even see the point of trying to include both? What would you accomplish by that? The entire point of having two libraries is that you want to be able to have full workstation capabilities, but then be dependent on the X11 libraries, or have limited capabilities, but skip the X11 dependency. > src/java.base/unix/native/libjli/java_md.c line 300: > >> 298: char jvmcfg[], jint so_jvmcfg) { >> 299: /* Compute/set the name of the executable. This is needed for macOS. */ >> 300: SetExecname(*pargv); > > Why is `SetExecname()` needed for the static case? Because of how macOS re-exec the launcher to reserve the main thread for GUI operations. Please check the rather extensive documentation elsewhere in this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745171016 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745172749 From ihse at openjdk.org Thu Sep 5 10:05:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 5 Sep 2024 10:05:56 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Wed, 4 Sep 2024 23:24:13 GMT, Jiangli Zhou wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > make/StaticLibs.gmk line 1: > >> 1: # > > Perhaps also consider adopting StaticLink.gmk file name from the https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch, as we are mostly doing the static linking here. Creating the static libs is handled elsewhere. My intention is to move all relevant handling of static linking into this file. > make/StaticLibs.gmk line 118: > >> 116: OPTIMIZATION := HIGH, \ >> 117: STATIC_LAUNCHER := true, \ >> 118: LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \ > > I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined. > > On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923. You are right, this is dead code. Thanks for spotting this. During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole. However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745180739 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745180044 From alanb at openjdk.org Thu Sep 5 10:19:51 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 5 Sep 2024 10:19:51 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com> On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). src/java.base/unix/native/libjli/java_md.c line 509: > 507: > 508: if (GetApplicationHome(path, pathsize)) { > 509: if (JLI_IsStaticallyLinked()) { In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745198354 From erikj at openjdk.org Thu Sep 5 13:18:53 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 5 Sep 2024 13:18:53 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [x] GHA Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20853#pullrequestreview-2283030584 From erikj at openjdk.org Thu Sep 5 13:25:57 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 5 Sep 2024 13:25:57 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: <70uj5_TjW-1jYey-WUgG64Vx2bAxPyGDLDL3IKFWT-E=.9a951e55-bf48-4c05-bbdb-ceeda6bb2304@github.com> On Thu, 5 Sep 2024 13:16:41 GMT, Erik Joelsson wrote: >> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. >> >> But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. >> >> [1] https://snapshot.debian.org/ >> [2] https://lists.debian.org/debian-snapshot/ >> >> Testing: >> - [x] GHA > > Marked as reviewed by erikj (Reviewer). > @erikj79 : Please take a look. Thanks. > Maybe @erikj79 ? Thanks. I generally skip most GHA related PRs as there are plenty of other reviewers on this mailing list with deeper GHA knowledge than I have, and it's not a focus for my current role at my employer. This patch was however small enough so I was comfortable approving it. Tagging me, or someone else, specifically in a PR, requesting a review with the intent of getting it quicker, will likely just have the opposite effect as it may deter other people from jumping in to review, thinking you already have some kind of agreement with the person being tagged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20853#issuecomment-2331674850 From fyang at openjdk.org Thu Sep 5 13:49:51 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 5 Sep 2024 13:49:51 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: <70uj5_TjW-1jYey-WUgG64Vx2bAxPyGDLDL3IKFWT-E=.9a951e55-bf48-4c05-bbdb-ceeda6bb2304@github.com> References: <70uj5_TjW-1jYey-WUgG64Vx2bAxPyGDLDL3IKFWT-E=.9a951e55-bf48-4c05-bbdb-ceeda6bb2304@github.com> Message-ID: On Thu, 5 Sep 2024 13:23:14 GMT, Erik Joelsson wrote: >> Marked as reviewed by erikj (Reviewer). > >> @erikj79 : Please take a look. Thanks. > >> Maybe @erikj79 ? Thanks. > > I generally skip most GHA related PRs as there are plenty of other reviewers on this mailing list with deeper GHA knowledge than I have, and it's not a focus for my current role at my employer. This patch was however small enough so I was comfortable approving it. > > Tagging me, or someone else, specifically in a PR, requesting a review with the intent of getting it quicker, will likely just have the opposite effect as it may deter other people from jumping in to review, thinking you already have some kind of agreement with the person being tagged. @erikj79: Thanks for having a look. The reason why I tagged you is that I was thinking that you as a reviewer of the previous https://github.com/openjdk/jdk/pull/18435 might be more familar with the background of this GHA issue. But you are right. Apologies anyway :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20853#issuecomment-2331727796 From jiangli at openjdk.org Thu Sep 5 19:21:52 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 19:21:52 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> <7tmo9e9RcUi06DYLjvQEaEu_XCY4bUa4OcWByw7vCdc=.11672bb7-71ca-46f4-8ed1-48512ab59e15@github.com> Message-ID: On Thu, 5 Sep 2024 09:50:49 GMT, Magnus Ihse Bursie wrote: > Well, but your proof-of-concept only supports clang on linux, where you have enabled symbol hiding. The hermetic-java-runtime branch doesn't have general symbol hiding enabled. That's why I'm wondering what the issues are with these libs except for `libjawt` with the current PR. (A side-note on `libjawt.a`: For static linking, we don't need `libjawt.a` and the headless or headful libs can be directly statically linked with.) > > Our conclusion in the zoom talks was that we should strive for getting a static launcher build pushed into mainline before we have full and proper support for symbol hiding on all platforms. Right, that would be a good & practical way to add the support in the mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746051842 From jiangli at openjdk.org Thu Sep 5 20:39:51 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 20:39:51 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters wrote: >> make/StaticLibs.gmk line 71: >> >>> 69: # libsspi_bridge has name conflicts with sunmscapi >>> 70: BROKEN_STATIC_LIBS += sspi_bridge >>> 71: # These libs define DllMain which conflict with Hotspot >> >> I'm not aware of the DllMain issue with static linking these libs. Could you please explain? The libawt.a and libdt_socket.a are statically linked with `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ branch. > > DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMai n when compiling them as static libraries @TheShermanTanker thanks for the details on DllMain issue. Right, we have only tested hermetic/static Java on Linux. I agree that hiding DllMain is not the right approach. One possible solution is to put the DllMain in separate .c/.cpp files and only link with those when building the .dll. With the current PR, we mainly focuses on the Linux (or unix-like) port, e.g. `os::lookup_function()` is not supported in the Windows port yet. Any thoughts on if we only limit static linking these affected JDK libraries on Windows initially, and allow statically linking more libs on Linux? We can add those libs on Windows when we resolve the DllMain issue. For running some minimum jtreg testing initially, I think we would want to include `libnet` (and other libs) in the statically linked `java` binary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746129101 From jiangli at openjdk.org Thu Sep 5 20:43:52 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 20:43:52 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Thu, 5 Sep 2024 10:03:19 GMT, Magnus Ihse Bursie wrote: >> make/StaticLibs.gmk line 118: >> >>> 116: OPTIMIZATION := HIGH, \ >>> 117: STATIC_LAUNCHER := true, \ >>> 118: LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \ >> >> I could be missing something, but I don't see where is $JAVASTATIC_LINK_LDFLAGS defined. >> >> On a related notes, I think we need to include $JVM_LDFLAGS when linking the static "java". See https://bugs.openjdk.org/browse/JDK-8339522?focusedId=14702923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14702923. > > You are right, this is dead code. Thanks for spotting this. > > During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole. > > However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING. +1 on "separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING" I think we need to get the linker flags sorted out correctly in this initial PR and make sure the needed flags (most importantly the ones used in $JVM_LDFLAGS). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746133505 From jiangli at openjdk.org Thu Sep 5 20:47:50 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 5 Sep 2024 20:47:50 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> Message-ID: On Thu, 5 Sep 2024 09:57:15 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.desktop/lib/AwtLibraries.gmk line 176: >> >>> 174: >>> 175: ifneq ($(ENABLE_HEADLESS_ONLY), true) >>> 176: # We cannot link with both awt_headless and awt_xawt at the same time >> >> Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java. > > That would require quite some work then..! The two libraries are meant as exclusive complements to each other -- they both implement the same "entry points", but in different ways -- one with X11 support, and one without. For other reasons (outside of static launcher reasons) I'd like to see some refactoring in how this is implemented, but that is completely outside this discussion. > > For the static launcher scenario, I can't even see the point of trying to include both? What would you accomplish by that? > > The entire point of having two libraries is that you want to be able to have full workstation capabilities, but then be dependent on the X11 libraries, or have limited capabilities, but skip the X11 dependency. My initial understanding was that the libawt_headless was mostly as subset of libawt_xawt, which made it possible to statically link both the headless and headful natives. Completely agree that it's outside of the current scope. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746136942 From kcr at openjdk.org Thu Sep 5 21:16:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Sep 2024 21:16:58 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. The GHA run shows a spurious failure in macOS (a network timeout cloning the repo). I'll rerun it with no changes to my branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2332635931 From kcr at openjdk.org Thu Sep 5 21:16:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Sep 2024 21:16:58 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal Message-ID: Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. This PR does two things: 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. ------------- Commit messages: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal Changes: https://git.openjdk.org/jdk/pull/20555/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311530 Stats: 27 lines in 7 files changed: 17 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555 From rriggs at openjdk.org Fri Sep 6 01:54:55 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 6 Sep 2024 01:54:55 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: References: Message-ID: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com> On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. Looks good. I'll review the CSR when its ready. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20555#pullrequestreview-2284421844 From fyang at openjdk.org Fri Sep 6 02:04:59 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 6 Sep 2024 02:04:59 GMT Subject: RFR: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: <-QcmbCIUUV7Rk-8teBMJVPq6QjfdsKHlLeaVdmV-rN4=.2a6f657e-08f9-40a7-9fe1-77ba9404f3e2@github.com> On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [x] GHA I see GHA linux-cross-build job for RISC-V is still skipped due to broken sysroot. Let's get this integrated to reactivate this job. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20853#issuecomment-2333042324 From fyang at openjdk.org Fri Sep 6 02:05:00 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 6 Sep 2024 02:05:00 GMT Subject: Integrated: 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote: > Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use for debootstrapping RISC-V breaks very often. Currently, the GHA linux-cross-build for RISC-V would not continue and is simply skipped when this debootstrap for "sid" repos fails. (See [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960) for more details). This is affecting GHA linux-cross-build for RISC-V for quite some time. As a result, we failed to catch some early build issues. > > But I don't think we need to catch up with the latest Debian "unstable" for our GHA verification purpose. So one way would be using some older but working Debian shapshot [1] [2] for our purpose. I find the most recent usable shapshot is https://snapshot.debian.org/archive/debian/20240228T034848Z/. We can switch back to more stable Debian repo once it graduates. > > [1] https://snapshot.debian.org/ > [2] https://lists.debian.org/debian-snapshot/ > > Testing: > - [x] GHA This pull request has now been integrated. Changeset: 9e0ccb8b Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/9e0ccb8bbd01ffbac466288977a770dd09e357af Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8339548: GHA: RISC-V: Use Debian snapshot archive for bootstrap Reviewed-by: shade, erikj ------------- PR: https://git.openjdk.org/jdk/pull/20853 From alanb at openjdk.org Fri Sep 6 05:39:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Sep 2024 05:39:55 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. The changes to make jdk.jsobject an upgradeable module looks right. I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20555#pullrequestreview-2284861631 From kcr at openjdk.org Fri Sep 6 13:18:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 13:18:49 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com> References: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com> Message-ID: On Fri, 6 Sep 2024 01:52:10 GMT, Roger Riggs wrote: > Looks good. I'll review the CSR when its ready. Thanks. > The changes to make jdk.jsobject an upgradeable module looks right. Thanks for checking. My testing primarily focused on this aspect of the change, so it's pretty well tested. > I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay. Yeah, I tried a few variants and couldn't come up with anything better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2334035899 From naoto at openjdk.org Fri Sep 6 17:49:37 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 6 Sep 2024 17:49:37 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules Message-ID: Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20893/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339644 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/20893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893 PR: https://git.openjdk.org/jdk/pull/20893 From naoto at openjdk.org Fri Sep 6 18:10:33 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 6 Sep 2024 18:10:33 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2] In-Reply-To: References: Message-ID: > Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixing failing test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20893/files - new: https://git.openjdk.org/jdk/pull/20893/files/22419a93..8e711667 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=00-01 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893 PR: https://git.openjdk.org/jdk/pull/20893 From jlu at openjdk.org Fri Sep 6 18:32:04 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 6 Sep 2024 18:32:04 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 18:10:33 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixing failing test Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2286928368 From coffeys at openjdk.org Fri Sep 6 18:38:06 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 6 Sep 2024 18:38:06 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v2] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 18:10:33 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixing failing test Thanks for fixing up. Looks good! ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2286938200 From gerard.ziemski at oracle.com Fri Sep 6 19:55:49 2024 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 6 Sep 2024 19:55:49 +0000 Subject: Is it possible to have the build in github's PR checks section to keep compiling files after an error? Message-ID: hi, Is it possible to have the build in github's PR checks section keep compiling files after an error is encountered? This would help limit number of times a fix and commit is required, for a large changes involving refactoring/renaming changes that touch lots of files. This in turn would limit the number of times the build must be spun up to find/fix all errors. As it is, the current build check task bails out at 1st error, and only provides error reports for a single file at a time. cheers From naoto at openjdk.org Fri Sep 6 21:49:30 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 6 Sep 2024 21:49:30 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3] In-Reply-To: References: Message-ID: > Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Strictly conforming to the spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20893/files - new: https://git.openjdk.org/jdk/pull/20893/files/8e711667..5d5c2019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20893&range=01-02 Stats: 80 lines in 3 files changed: 17 ins; 26 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/20893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20893/head:pull/20893 PR: https://git.openjdk.org/jdk/pull/20893 From naoto at openjdk.org Fri Sep 6 21:54:09 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 6 Sep 2024 21:54:09 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3] In-Reply-To: References: Message-ID: <5lj0AD5gQvxIaVZgtRKcEfrA3ar9sS9fSVeH1wX8ls4=.264ea7d7-d841-4a98-80ca-734b960ffb29@github.com> On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Strictly conforming to the spec Had to modify the fix. According to zic(8): Names must be in English and are case insensitive. They appear in several contexts, and include month and weekday names and keywords such as ?maximum?, ?only?, ?Rolling?, and ?Zone?. A name can be abbreviated by omitting all but an initial prefix; any abbreviation must be unambiguous in context Thus April can not only either "Apr" or "April", but also "apr", "april", "apri", or "Ap". The fix assumes the source tz files already have unbiguous names. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2334857393 From jlu at openjdk.org Fri Sep 6 22:19:23 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 6 Sep 2024 22:19:23 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Strictly conforming to the spec Marked as reviewed by jlu (Committer). New fix LGTM. > Month names may be abbreviated as mentioned previously; > for example, January can appear as > .q January , > .q JANU > or > .q Ja , > but not as > .q j So I think it's safe to assume unambiguous abbreviations. ------------- PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2287223428 PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2334879456 From coffeys at openjdk.org Mon Sep 9 06:31:04 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 9 Sep 2024 06:31:04 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Strictly conforming to the spec Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20893#pullrequestreview-2288924261 From syan at openjdk.org Mon Sep 9 09:56:13 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 09:56:13 GMT Subject: RFR: 8339714: Delete tedious bool type define Message-ID: Hi all, This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. Make code more concision, the risk is quite low. Additional testing: - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 ------------- Commit messages: - 8339714: Delete tedious bool type define Changes: https://git.openjdk.org/jdk/pull/20909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339714 Stats: 14 lines in 2 files changed: 1 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20909/head:pull/20909 PR: https://git.openjdk.org/jdk/pull/20909 From rkennke at openjdk.org Mon Sep 9 10:29:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 10:29:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v7] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Fix compiler/c2/irTests/TestPadding.java for +COH - Simplify arrayOopDesc::length_offset_in_bytes and oopDesc::base_offset_in_bytes - Nit in header_size - GC code tweaks - Fix runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java - Fix jdk/tools/jlink/plugins/CDSPluginTest.java - Cleanup markWord bits and comments - x86_64: Fix loadNKlassCompactHeaders - aarch64: Fix loadNKlassCompactHeaders - Use FLAG_SET_ERGO when turning off UseCompactObjectHeaders - ... and 16 more: https://git.openjdk.org/jdk/compare/b45fe174...49126383 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=06 Stats: 4465 lines in 189 files changed: 3175 ins; 678 del; 612 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Mon Sep 9 11:55:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 11:55:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Try to avoid lea in loadNklass (aarch64) - Fix release build error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/49126383..70f492d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=06-07 Stats: 24 lines in 5 files changed: 12 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From jwaters at openjdk.org Mon Sep 9 12:10:09 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 9 Sep 2024 12:10:09 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 Hmm. While I want to put my support behind this change, I recall that an earlier proposal that I made to implement jbooleans with stdbool.h being rejected due to backwards incompatibility, and some places really do expect an int and not a bool type. What are the likelihoods that a place in the code here is actually expecting an int due to ABI issues? src/java.base/unix/native/libjsig/jsig.c line 46: > 44: #include > 45: > 46: #if (__STDC_VERSION__ >= 199901L) Since this does include stdbool.h already, this change looks ok src/utils/hsdis/binutils/hsdis-binutils.c line 67: > 65: #include "hsdis.h" > 66: > 67: #ifndef bool I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2337942768 PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750135891 PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750137910 From tschatzl at openjdk.org Mon Sep 9 12:40:13 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 9 Sep 2024 12:40:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v7] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 10:29:55 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Fix compiler/c2/irTests/TestPadding.java for +COH > - Simplify arrayOopDesc::length_offset_in_bytes and oopDesc::base_offset_in_bytes > - Nit in header_size > - GC code tweaks > - Fix runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java > - Fix jdk/tools/jlink/plugins/CDSPluginTest.java > - Cleanup markWord bits and comments > - x86_64: Fix loadNKlassCompactHeaders > - aarch64: Fix loadNKlassCompactHeaders > - Use FLAG_SET_ERGO when turning off UseCompactObjectHeaders > - ... and 16 more: https://git.openjdk.org/jdk/compare/b45fe174...49126383 src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 481: > 479: Klass* klass = UseCompactObjectHeaders > 480: ? old_mark.klass() > 481: : old->klass(); To be exact "promotion" only refers to copying to an older generation, so this comment does not cover objects copied within the generation. Suggestion: // NOTE: With compact headers, it is not safe to load the Klass* from old, because // that would access the mark-word, that might change at any time by concurrent // workers. // This mark word would refer to a forwardee, which may not yet have completed // copying. Therefore we must load the Klass* from the mark-word that we already // loaded. This is safe, because we only enter here if not yet forwarded. src/hotspot/share/gc/parallel/mutableSpace.cpp line 225: > 223: // header-based forwarding during promotion. Full GC doesn't > 224: // use the object header for forwarding at all. > 225: p += obj->forwardee()->size(); Better use `!obj->is_self_forwarded()` here. src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 174: > 172: // may not yet have completed copying. Therefore we must load the Klass* from > 173: // the mark-word that we have already loaded. This is safe, because we have checked > 174: // that this is not yet forwarded in the caller.) Same adjustment needed as for G1. src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 711: > 709: // 8 - 32-bit VM > 710: // 12 - 64-bit VM, compressed klass > 711: // 16 - 64-bit VM, normal klass The comment needs to be adapted to include the case for compact object headers. src/hotspot/share/oops/arrayOop.hpp line 83: > 81: // The _length field is not declared in C++. It is allocated after the > 82: // declared nonstatic fields in arrayOopDesc if not compressed, otherwise > 83: // it occupies the second half of the _klass field in oopDesc. Needs update. src/hotspot/share/oops/instanceOop.hpp line 36: > 34: class instanceOopDesc : public oopDesc { > 35: public: > 36: // If compressed, the offset of the fields of the instance may not be aligned. Needs fixing (or removal) wrt to compact object headers, or move to the particular case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750046114 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750056160 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750074607 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750080552 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750027009 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750116336 From tschatzl at openjdk.org Mon Sep 9 12:40:14 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 9 Sep 2024 12:40:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix bit counts in GCForwarding src/hotspot/share/gc/shared/collectedHeap.cpp line 232: > 230: } > 231: > 232: // With compact headers, we can't safely access the class, due Suggestion: // With compact headers, we can't safely access the klass, due This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable? Given this is used for verification only afaik, we should make an effort to provide that check. src/hotspot/share/gc/shared/gcForwarding.hpp line 34: > 32: > 33: /* > 34: * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in Suggestion: * Implements forwarding for the Full GCs of Serial, Parallel, G1 and Shenandoah in src/hotspot/share/gc/shared/gcForwarding.hpp line 41: > 39: * bits (to indicate 'forwarded' state as usual). > 40: */ > 41: class GCForwarding : public AllStatic { Since this class is only used for Full GCs, it may be useful to include that information, i.e. something like `FullGCForwarding` to avoid confusion why it is not used for other GCs too. (Unless this has been discussed and even rejected by me before). src/hotspot/share/oops/compressedKlass.hpp line 43: > 41: > 42: // Tiny-class-pointer mode > 43: static int _tiny_cp; // -1, 0=true, 1=false Suggestion: static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749995275 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749980748 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749987945 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1749969456 From tschatzl at openjdk.org Mon Sep 9 12:40:18 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 9 Sep 2024 12:40:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Try to avoid lea in loadNklass (aarch64) > - Fix release build error src/hotspot/share/oops/klass.hpp line 169: > 167: // contention that may happen when a nearby object is modified. > 168: AccessFlags _access_flags; // Access flags. The class/interface distinction is stored here. > 169: // Some flags created by the JVM, not in the class file itself, Suggestion: markWord _prototype_header; // Used to initialize objects' header with compact headers. Maybe some comment why this is an instance member. src/hotspot/share/oops/objArrayKlass.inline.hpp line 74: > 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) { > 73: // In this assert, we cannot safely access the Klass* with compact headers. > 74: assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array"); If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe? src/hotspot/share/oops/oop.cpp line 157: > 155: bool oopDesc::has_klass_gap() { > 156: // Only has a klass gap when compressed class pointers are used. > 157: // Except when using compact headers. Suggestion: // Only has a klass gap when compressed class pointers are used and not // using compact headers. (Not sure if repeating the fairly simple disjunction below makes sense, but there has been a comment before too) src/hotspot/share/oops/oop.cpp line 230: > 228: // disjunct below to fail if the two comparands are computed across such > 229: // a concurrent change. > 230: return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC); Is this still true after the recent changes like JDK-8311163? It might be worth waiting for. src/hotspot/share/oops/oop.hpp line 103: > 101: static inline void set_klass_gap(HeapWord* mem, int z); > 102: > 103: // size of object header, aligned to platform wordSize Suggestion: // Size of object header, aligned to platform wordSize Pre-existing src/hotspot/share/oops/oop.hpp line 108: > 106: return sizeof(markWord) / HeapWordSize; > 107: } else { > 108: return sizeof(oopDesc) / HeapWordSize; Suggestion: return sizeof(oopDesc) / HeapWordSize; src/hotspot/share/oops/oop.hpp line 134: > 132: inline Klass* forward_safe_klass(markWord m) const; > 133: inline size_t forward_safe_size(); > 134: inline void forward_safe_init_mark(); Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them. Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe". src/hotspot/share/oops/oop.hpp line 295: > 293: // this call returns null for that thread; any other thread has the > 294: // value of the forwarding pointer returned and does not modify "this". > 295: inline oop forward_to_atomic(oop p, markWord compare, atomic_memory_order order = memory_order_conservative); Maybe add an assert in the implementation so that it is not used for self-forwarding. Same for `forward_to`. src/hotspot/share/oops/oop.hpp line 356: > 354: return mark_offset_in_bytes() + sizeof(markWord) / 2; > 355: } else > 356: #endif Maybe instead of trying to calculate some random, meaningless value just use some "random" value directly? I am fine with the existing code, but first stating directly that "any value" works here, this additional code seems to confuse the message. (Fwiw, the method is also used during Universe initialization). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750118470 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750143956 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750145460 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750150640 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750154114 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750153663 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750157781 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750159516 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750163768 From tschatzl at openjdk.org Mon Sep 9 12:45:07 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 9 Sep 2024 12:45:07 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Try to avoid lea in loadNklass (aarch64) > - Fix release build error Only looked at GC and runtime changes, only very briefly at compiler stuff. Only looked at GC and runtime changes, only very briefly at compiler stuff. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2289786482 PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2289800458 From rkennke at openjdk.org Mon Sep 9 12:52:07 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 12:52:07 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v3] In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 18:10:44 GMT, Albert Mingkun Yang wrote: >> FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers. >> >> Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE. > >> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. > > True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from. ParallelGC actually doesn't use bitmaps, it pushes all forwarded objs to preserved-marks-table, and uses that to find forwarded objects, which is why we can't remove the preserved-marks table in ParallelGC (IOW, after this patch, the preserved-marks-stuff in Parallel scavenger is *only* used to find forwarded objects. We might want to think about more efficient solutions for this). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750199051 From syan at openjdk.org Mon Sep 9 12:53:06 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:53:06 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:06:25 GMT, Julian Waters wrote: >> Hi all, >> This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. >> Make code more concision, the risk is quite low. >> >> Additional testing: >> >> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils >> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 >> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 > > src/java.base/unix/native/libjsig/jsig.c line 46: > >> 44: #include >> 45: >> 46: #if (__STDC_VERSION__ >= 199901L) > > Since this does include stdbool.h already, this change looks ok Okey. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750201356 From syan at openjdk.org Mon Sep 9 12:59:06 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 12:59:06 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:07:54 GMT, Julian Waters wrote: >> Hi all, >> This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. >> Make code more concision, the risk is quite low. >> >> Additional testing: >> >> - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils >> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 >> - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 > > src/utils/hsdis/binutils/hsdis-binutils.c line 67: > >> 65: #include "hsdis.h" >> 66: >> 67: #ifndef bool > > I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750211438 From rkennke at openjdk.org Mon Sep 9 13:02:08 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 13:02:08 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v5] In-Reply-To: <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com> References: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com> <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com> Message-ID: On Fri, 30 Aug 2024 07:42:39 GMT, Thomas Stuefe wrote: >> Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO. > > Seems we run all into the same thoughts :) > > I added > > Suggestion: > > FLAG_SET_DEFAULT(UseCompactObjectHeaders, false); > warning("Compact object headers require a java heap size smaller than %zu (given: %zu). " > "Disabling compact object headers.", max_narrow_heap_size * HeapWordSize, max_heap_size); That %zu is SIZE_FORMAT, right? This should probably use proper_unit_for_byte_size()/byte_size_in_proper_unit(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750215510 From jwaters at openjdk.org Mon Sep 9 13:06:06 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 9 Sep 2024 13:06:06 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: <55oOaRmeL9m8LqNBmJgL3HKHI5QJ0WHm4ahcOneNt8k=.bfa57937-f3fe-41d3-b514-3d5444bde093@github.com> On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [ ] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20909#pullrequestreview-2289852123 From jwaters at openjdk.org Mon Sep 9 13:06:07 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 9 Sep 2024 13:06:07 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:56:56 GMT, SendaoYan wrote: >> src/utils/hsdis/binutils/hsdis-binutils.c line 67: >> >>> 65: #include "hsdis.h" >>> 66: >>> 67: #ifndef bool >> >> I'm a little worried about this change. hsdis may really need an int here. If that turns out to not be the case then I'll retract my concerns > > I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally. Ok, sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750222067 From syan at openjdk.org Mon Sep 9 13:20:07 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 9 Sep 2024 13:20:07 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 13:03:49 GMT, Julian Waters wrote: >> I have verified this change locally, include build hsdis.so and check the functional with command java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version. The verified show this change for hsdis.so work normally. > > Ok, sounds good Thanks for the review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20909#discussion_r1750243576 From rkennke at openjdk.org Mon Sep 9 13:31:10 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 13:31:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v5] In-Reply-To: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com> References: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com> Message-ID: On Thu, 22 Aug 2024 19:50:21 GMT, Albert Mingkun Yang wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix hash shift for 32 bit builds > > src/hotspot/share/gc/shared/gcForwarding.hpp line 36: > >> 34: * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in >> 35: * a way that preserves upper N bits of object mark-words, which contain crucial >> 36: * Klass* information when running with compact headers. The encoding is similar to > > This doc suggests this forwarding is only for compact-header so I wonder if we can check `UseCompactObjectHeaders` directly instead of heap-size in `GCForwarding::initialize`. Right. The original implementation was more complex and then the consensus was to not sprinkle UseCompactHeaders all over the place, but with that new/simpler implementation it makes sense to simply check the UCOH flag. > src/hotspot/share/gc/shared/gcForwarding.hpp line 40: > >> 38: * heap-base, shifts that difference into the right place, and sets the lowest two >> 39: * bits (to indicate 'forwarded' state as usual). >> 40: */ > >> "can use 40 bits for forwardee encoding. That's enough for 8TB of heap." > > I feel this 8T-constraint is significant and should be in the doc. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750264571 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750265026 From rkennke at openjdk.org Mon Sep 9 14:11:08 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 14:11:08 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com> On Tue, 27 Aug 2024 07:43:07 GMT, Hamlin Li wrote: >> @Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-) > > Yes, I'm interested in it. Thanks for raising the discussion. :) If anybody is doing it, please send me a patch, or we can do it as a follow-up PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750345203 From rkennke at openjdk.org Mon Sep 9 14:11:10 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 14:11:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Fri, 23 Aug 2024 11:38:39 GMT, Hamlin Li wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/oops/oop.inline.hpp line 94: > >> 92: >> 93: void oopDesc::init_mark() { >> 94: if (UseCompactObjectHeaders) { > > Seems only `set_mark(prototype_mark());` is fine for both cases? Right. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750342555 From rkennke at openjdk.org Mon Sep 9 14:35:08 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 14:35:08 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Mon, 26 Aug 2024 21:52:58 GMT, Chris Plummer wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169: > >> 167: } else { >> 168: visitor.doMetadata(klass, true); >> 169: } > > Why is there no `visitor.doMetadata()` call for the compact object header case? There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750386024 From stefank at openjdk.org Mon Sep 9 14:50:10 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Sep 2024 14:50:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com> On Fri, 30 Aug 2024 08:06:31 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/cds/filemap.cpp line 2507: > >> 2505: } >> 2506: >> 2507: if (compact_headers() != UseCompactObjectHeaders) { > > (Commenting here, but the comment applies to code a bit above) While debugging CDS, it would have been useful to print the value of UseCompactObjectHeaders. > > Could we change the code to be: > > log_info(cds)("Archive was created with UseCompressedOops = %d, UseCompressedClassPointers = %d, UseCompactObjectHeaders = %d", > compressed_oops(), compressed_class_pointers(), compact_headers()); Resolved. > src/hotspot/share/cds/filemap.cpp line 2508: > >> 2506: >> 2507: if (compact_headers() != UseCompactObjectHeaders) { >> 2508: log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)" > > Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'. @iklam informed me that some of the info levels (including this line) should be converted to warning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750408043 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750410679 From rkennke at openjdk.org Mon Sep 9 15:04:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 15:04:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com> References: <4yTWbD93OXGwYYxEQo56smKa5kl_WiPPcMsXSs0eUoQ=.893f54c8-ed2b-4a7f-bf0a-36553a951f47@github.com> Message-ID: <-2JWx3F8EdyQ0Uf-mI62ImLXgjgIy9PEydjtKHhx12Q=.4d944301-6f1c-4270-953c-ec6c86df946a@github.com> On Mon, 9 Sep 2024 14:47:28 GMT, Stefan Karlsson wrote: >> src/hotspot/share/cds/filemap.cpp line 2508: >> >>> 2506: >>> 2507: if (compact_headers() != UseCompactObjectHeaders) { >>> 2508: log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)" >> >> Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'. > > @iklam informed me that some of the info levels (including this line) should be converted to warning. Yeah that looks inconsistent with other places where we print a warning instead. I'll change it to warning for the UCOH check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750430001 From stefank at openjdk.org Mon Sep 9 15:04:12 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Sep 2024 15:04:12 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 12:21:19 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/oop.hpp line 134: > >> 132: inline Klass* forward_safe_klass(markWord m) const; >> 133: inline size_t forward_safe_size(); >> 134: inline void forward_safe_init_mark(); > > Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them. > > Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe". Restating my earlier comment about this: These functions are mainly used by the GCs. In one of the patches I've cleaned away all usages except for those in Shenandoah. I would prefer to see these completely removed from the oops/ directory and let the GCs decide when and how to perform "safe" reads of these values. > src/hotspot/share/oops/oop.hpp line 356: > >> 354: return mark_offset_in_bytes() + sizeof(markWord) / 2; >> 355: } else >> 356: #endif > > Maybe instead of trying to calculate some random, meaningless value just use some "random" value directly? > I am fine with the existing code, but first stating directly that "any value" works here, this additional code seems to confuse the message. (Fwiw, the method is also used during Universe initialization). Just to be clear, the second part of the quoted sentence is important: > could be any value *that is not a valid field offset* ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750428581 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750432186 From tschatzl at openjdk.org Mon Sep 9 15:04:12 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 9 Sep 2024 15:04:12 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 15:00:09 GMT, Stefan Karlsson wrote: > could be any value that is not a valid field offset I understand that that "random value" needs to satisfy this condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750433800 From stefank at openjdk.org Mon Sep 9 15:34:09 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Sep 2024 15:34:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v3] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 12:49:05 GMT, Roman Kennke wrote: >>> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. >> >> True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from. > > ParallelGC actually doesn't use bitmaps, it pushes all forwarded objs to preserved-marks-table, and uses that to find forwarded objects, which is why we can't remove the preserved-marks table in ParallelGC (IOW, after this patch, the preserved-marks-stuff in Parallel scavenger is *only* used to find forwarded objects. We might want to think about more efficient solutions for this). (Just to clarify if others are reading this) Right, what I referred to above was how we found the object to forward, which is done via the bitmaps: while (cur_addr < region_end) { cur_addr = mark_bitmap()->find_obj_beg(cur_addr, region_end); If the Parallel Old collector didn't do that, but instead parsed the heap like Serial does, then the Parallel Young collector would also have to fix the from space copies of moved objects when when it hits a promotion failure, just like Serial does. This was just meant to point out the differences between the two collectors and why the young GC code is different. I realize that in earlier comments I called the from-space copy of the objects "dead objects", but they are not dead they are just the stale objects that are discoverable because of promotion failure keeping the eden and from spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750480983 From stefank at openjdk.org Mon Sep 9 15:34:10 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Sep 2024 15:34:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v5] In-Reply-To: References: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com> <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com> Message-ID: On Mon, 9 Sep 2024 12:59:36 GMT, Roman Kennke wrote: > That %zu is SIZE_FORMAT, right? Yes. Reviewers have lately encouraged people to use %zu instead of SIZE_FORMAT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750482486 From naoto at openjdk.org Mon Sep 9 16:05:04 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 9 Sep 2024 16:05:04 GMT Subject: RFR: 8339644: Improve parsing of Day/Month in tzdata rules [v3] In-Reply-To: References: Message-ID: <1ctZ88OHCV_abfZ3lL4ae4accAhnqAL8ue_P-f_Nzt0=.d7eb0c9f-6671-4c14-993e-81957602f643@github.com> On Fri, 6 Sep 2024 21:49:30 GMT, Naoto Sato wrote: >> Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Strictly conforming to the spec Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20893#issuecomment-2338507731 From naoto at openjdk.org Mon Sep 9 16:08:08 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 9 Sep 2024 16:08:08 GMT Subject: Integrated: 8339644: Improve parsing of Day/Month in tzdata rules In-Reply-To: References: Message-ID: <9SLWFkmkkPGEBwR1Q4RJrxVFGdimaurZcS9SeMsTgO4=.fd678df3-d08b-4201-9e00-fc8899e46ac5@github.com> On Fri, 6 Sep 2024 17:40:50 GMT, Naoto Sato wrote: > Fixing TZDB build tool to accommodate full month/day names. Recently released tzdb2024b included (inadvertently) full month name "April", which is allowed by the spec (zic.8), but never used. This will cause build failure of the JDK. The proposed fix is manually tested by modifying the tzdb files to include full month names, and confirmed the successful build of the JDK. This pull request has now been integrated. Changeset: 86a2f9c7 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/86a2f9c7dcb6585cabf03c0940511d11560e85b7 Stats: 83 lines in 3 files changed: 23 ins; 26 del; 34 mod 8339644: Improve parsing of Day/Month in tzdata rules Reviewed-by: jlu, coffeys ------------- PR: https://git.openjdk.org/jdk/pull/20893 From cjplummer at openjdk.org Mon Sep 9 16:56:08 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 9 Sep 2024 16:56:08 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: <1VACYSoQRtP9m4BJkCVrdFxueC75Kg4Kp3wjGsAA2Dw=.53563f62-70cf-4d93-8d99-69b737812ba6@github.com> On Mon, 26 Aug 2024 21:30:51 GMT, Chris Plummer wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 85: > >> 83: >> 84: private static Klass getKlass(Mark mark) { >> 85: assert(VM.getVM().isCompactObjectHeadersEnabled()); > > `mark.getKlass()` already does this assert. I don't see any value in this `getKlass()` method. The caller should just call `getMark().getKlass()` rather than `getKlass(getMark())`. I'm not sure why this got marked as resolved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750600652 From cjplummer at openjdk.org Mon Sep 9 16:56:08 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 9 Sep 2024 16:56:08 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 14:32:49 GMT, Roman Kennke wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169: >> >>> 167: } else { >>> 168: visitor.doMetadata(klass, true); >>> 169: } >> >> Why is there no `visitor.doMetadata()` call for the compact object header case? > > There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt). I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following: hsdb> + inspect 0x00000007cff154b8 instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24) _mark: 1 _metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750598648 From rkennke at openjdk.org Mon Sep 9 17:45:47 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 9 Sep 2024 17:45:47 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: Message-ID: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: - Print as warning when UCOH doesn't match in CDS archive - Improve initialization of mark-word in CDS ArchiveHeapWriter - Simplify getKlass() in SA - Simplify oopDesc::init_mark() - Get rid of forward_safe_* methods - GCForwarding touch-ups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/70f492d3..2884499a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=07-08 Stats: 132 lines in 17 files changed: 26 ins; 73 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From cjplummer at openjdk.org Mon Sep 9 18:37:09 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 9 Sep 2024 18:37:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 16:51:35 GMT, Chris Plummer wrote: >> There is no dedicated klass field anymore, the Klass* is encoded in the mark, and we would need to extract it. What is the purpose of the visitors? Do they need to see the klass/compressedKlass, or is it sufficient to visit the mark-word (which we already do, but as CInt). > > I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following: > > > hsdb> + inspect 0x00000007cff154b8 > instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24) > _mark: 1 > _metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject > firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 > lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 > this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498 I pulled your changes and I see one slight difference in the output. The following line is missing: `_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject` I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output: _mark: 16294762323640321 So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750743693 From cjplummer at openjdk.org Mon Sep 9 19:07:10 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 9 Sep 2024 19:07:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 18:34:10 GMT, Chris Plummer wrote: >> I've been looking into this. It's a bit hard to follow but I think you do need to do something more here. Can you run ClhsdbInspect.java and send me the output. In specific I need to know if the log includes the following: >> >> >> hsdb> + inspect 0x00000007cff154b8 >> instance of Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject @ 0x00000007cff154b8 (size = 24) >> _mark: 1 >> _metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject >> firstWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 >> lastWaiter: Oop for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionNode @ 0x00000007cfff5f80 >> this$0: Oop for java/util/concurrent/locks/ReentrantLock$NonfairSync @ 0x00000007cff15498 > > I pulled your changes and I see one slight difference in the output. The following line is missing: > > `_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject` > > I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output: > > _mark: 16294762323640321 > > So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this. Thinking about this a bit more, maybe _mark needs to be a MetadataFile rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two seprate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750788243 From coleenp at openjdk.org Mon Sep 9 19:55:16 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Sep 2024 19:55:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Mon, 9 Sep 2024 17:45:47 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: > > - Print as warning when UCOH doesn't match in CDS archive > - Improve initialization of mark-word in CDS ArchiveHeapWriter > - Simplify getKlass() in SA > - Simplify oopDesc::init_mark() > - Get rid of forward_safe_* methods > - GCForwarding touch-ups I reviewed the oops code so far. src/hotspot/share/oops/compressedKlass.cpp line 116: > 114: _range = end - _base; > 115: > 116: DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);) Can you refactor so the aarch64 path runs this same code without duplication? src/hotspot/share/oops/klass.hpp line 173: > 171: > 172: markWord _prototype_header; // Used to initialize objects' header > 173: I think you should move this up after ClassLoaderData, as there might be an alignment gap (you can run pahole to check). src/hotspot/share/oops/klass.hpp line 718: > 716: > 717: markWord prototype_header() const { > 718: assert(UseCompactObjectHeaders, "only use with compact object headers"); Should this unconditionally return _prototype_header since it's initialized to markWord::prototype_header(), or would that decrease performance for the non-compact headers case? src/hotspot/share/oops/klass.inline.hpp line 54: > 52: } > 53: > 54: inline void Klass::set_prototype_header(markWord header) { Can you put a comment that this is only used when dumping the archive? Because otherwise the Klass::_prototype_header field should always be initialized to the right thing (either with Klass encoded or as markWord::protoytpe_header()) and doesn't change. src/hotspot/share/oops/markWord.inline.hpp line 90: > 88: ShouldNotReachHere(); > 89: return markWord(); > 90: #endif Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits? src/hotspot/share/oops/oop.inline.hpp line 90: > 88: } else { > 89: return markWord::prototype(); > 90: } Could this be unconditional since prototoype_header is initialized for all Klasses? src/hotspot/share/oops/typeArrayKlass.cpp line 175: > 173: size_t TypeArrayKlass::oop_size(oop obj) const { > 174: // In this assert, we cannot safely access the Klass* with compact headers. > 175: assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array"); Why not? I think I'm missing something. Klass should be in the markWord and that should be ok (?) ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2290316150 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750529270 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750727211 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750730078 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750736547 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750739441 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750842383 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750721069 From coleenp at openjdk.org Mon Sep 9 19:55:19 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Sep 2024 19:55:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 11:55:52 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Try to avoid lea in loadNklass (aarch64) > - Fix release build error src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147: > 145: #endif > 146: > 147: return true; This should only be in the compressedKlass.cpp file. src/hotspot/share/oops/compressedKlass.cpp line 214: > 212: ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)", > 213: len, max_encoding_range_size()); > 214: vm_exit_during_initialization(ss.base()); Why does this exit and not turn off compressed klass pointers and compact object headers? src/hotspot/share/oops/compressedKlass.cpp line 222: > 220: return; > 221: } > 222: #endif Why not add null pd_initialize to zero to remove this conditional code? src/hotspot/share/oops/compressedKlass.cpp line 224: > 222: #endif > 223: > 224: if (tiny_classpointer_mode()) { I kind of agree with Thomas Schatzl for this. Maybe it should be compact_classpointer_mode(). It's nice to have a new string for grep, but they're not really that tiny. src/hotspot/share/oops/compressedKlass.cpp line 234: > 232: _range = len; > 233: > 234: constexpr int log_cacheline = 6; Is 6 the log of DEFAULT_CACHE_LINE_SIZE? src/hotspot/share/oops/compressedKlass.cpp line 243: > 241: } else { > 242: > 243: // In legacy mode, we try, in order of preference: Can you not use the word 'legacy' here? Maybe in "non-compact object header mode"... src/hotspot/share/oops/compressedKlass.inline.hpp line 100: > 98: check_valid_klass(k, base(), shift()); > 99: // Also assert that k falls into what we know is the valid Klass range. This is usually smaller > 100: // than the encoding range (e.g. encoding range covers 4G, but we only have 1G class space and a 1G is the default CompressedClassSpaceSize but can be larger, right? So the comment isn't quite accurate. Or with tiny class pointers can it only be 1G? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750527537 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750511912 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750513660 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750515923 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750520712 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750524690 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750662637 From coleenp at openjdk.org Mon Sep 9 19:55:20 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Sep 2024 19:55:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> References: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> Message-ID: <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com> On Mon, 9 Sep 2024 10:02:53 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/oops/compressedKlass.hpp line 43: > >> 41: >> 42: // Tiny-class-pointer mode >> 43: static int _tiny_cp; // -1, 0=true, 1=false > > Suggestion: > > static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false > > In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style. I agree with this. 'cp' reads as ConstantPool for me even though this is a different context. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750531167 From stefank at openjdk.org Mon Sep 9 20:07:13 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 9 Sep 2024 20:07:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com> On Mon, 9 Sep 2024 18:15:38 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: >> >> - Print as warning when UCOH doesn't match in CDS archive >> - Improve initialization of mark-word in CDS ArchiveHeapWriter >> - Simplify getKlass() in SA >> - Simplify oopDesc::init_mark() >> - Get rid of forward_safe_* methods >> - GCForwarding touch-ups > > src/hotspot/share/oops/typeArrayKlass.cpp line 175: > >> 173: size_t TypeArrayKlass::oop_size(oop obj) const { >> 174: // In this assert, we cannot safely access the Klass* with compact headers. >> 175: assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array"); > > Why not? I think I'm missing something. Klass should be in the markWord and that should be ok (?) I tracked this down to only (at least in my testing) happen from `size_given_klass` when called from the GC when it is about to copy an object. While that happens another thread can racingly succeed to copy the object and install a forwarding pointer over the old copy. When that happens the klass pointer is broken and the call to oopDesc::is_typeArray() crashes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750862842 From coleenp at openjdk.org Mon Sep 9 20:23:11 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 9 Sep 2024 20:23:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com> References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> <1vlOROPKL6eDagcb0xz0MGe6vA6vYBVa4UzVsCZ5Q8I=.d5408660-ee94-4118-b809-d13a3dc500b4@github.com> Message-ID: On Mon, 9 Sep 2024 20:04:22 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/typeArrayKlass.cpp line 175: >> >>> 173: size_t TypeArrayKlass::oop_size(oop obj) const { >>> 174: // In this assert, we cannot safely access the Klass* with compact headers. >>> 175: assert(UseCompactObjectHeaders || obj->is_typeArray(),"must be a type array"); >> >> Why not? I think I'm missing something. Klass should be in the markWord and that should be ok (?) > > I tracked this down to only (at least in my testing) happen from `size_given_klass` when called from the GC when it is about to copy an object. While that happens another thread can racingly succeed to copy the object and install a forwarding pointer over the old copy. When that happens the klass pointer is broken and the call to oopDesc::is_typeArray() crashes. I did miss something. I thought the markWord was never overwritten by the forwarding pointer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1750882259 From bpb at openjdk.org Mon Sep 9 21:37:08 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 9 Sep 2024 21:37:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2339193692 From rkennke at openjdk.org Tue Sep 10 07:23:13 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 07:23:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> References: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> Message-ID: On Mon, 9 Sep 2024 10:16:24 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/gc/shared/gcForwarding.hpp line 41: > >> 39: * bits (to indicate 'forwarded' state as usual). >> 40: */ >> 41: class GCForwarding : public AllStatic { > > Since this class is only used for Full GCs, it may be useful to include that information, i.e. something like `FullGCForwarding` to avoid confusion why it is not used for other GCs too. > (Unless this has been discussed and even rejected by me before). I agree. In-fact, that has been my original name. It has been suggested that I change it to SlidingForwarding when that was the approach that we were going to take, but with the new implementation, FullGCForwarding makes most sense. I'll change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751400378 From rkennke at openjdk.org Tue Sep 10 07:56:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 07:56:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> References: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> Message-ID: On Mon, 9 Sep 2024 10:21:54 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/gc/shared/collectedHeap.cpp line 232: > >> 230: } >> 231: >> 232: // With compact headers, we can't safely access the class, due > > Suggestion: > > // With compact headers, we can't safely access the klass, due > > > This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable? > Given this is used for verification only afaik, we should make an effort to provide that check. With compact headers, we can't safely access the Klass* when the object has been forwarded, because non-full-GC-forwarding temporarily overwrites the mark-word, and thus the Klass*, with the forwarding pointer, and here we have no way to make a distinction between Full-GC and regular GC forwarding. I improved the code to make the check when the object is not forwarded. Not sure if we could/should do more (e.g. pass around is_full argument to make the distinction, or find the - possibly few - places where we might call is_oop() on from-space objects in regular GC and do the check in a forwardee-safe way?). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751448814 From rkennke at openjdk.org Tue Sep 10 08:36:13 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 08:36:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 14:58:07 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/oop.hpp line 134: >> >>> 132: inline Klass* forward_safe_klass(markWord m) const; >>> 133: inline size_t forward_safe_size(); >>> 134: inline void forward_safe_init_mark(); >> >> Given the comment these methods do not seem "safe" to me. Maybe use "raw" or something to better indicate that care must be taken to use them. >> >> Maybe the "safe" refers to use them only in "safe" contexts, but in Hotspot code iirc we use something like "raw" or "unsafe". > > Restating my earlier comment about this: These functions are mainly used by the GCs. In one of the patches I've cleaned away all usages except for those in Shenandoah. I would prefer to see these completely removed from the oops/ directory and let the GCs decide when and how to perform "safe" reads of these values. I've removed those methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751514466 From rkennke at openjdk.org Tue Sep 10 08:40:12 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 08:40:12 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 15:01:10 GMT, Thomas Schatzl wrote: >> Just to be clear, the second part of the quoted sentence is important: >>> could be any value *that is not a valid field offset* > >> could be any value that is not a valid field offset > > I understand that that "random value" needs to satisfy this condition. With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751522091 From rkennke at openjdk.org Tue Sep 10 08:44:11 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 08:44:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 12:12:23 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/objArrayKlass.inline.hpp line 74: > >> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) { >> 73: // In this assert, we cannot safely access the Klass* with compact headers. >> 74: assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array"); > > If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe? Good question. This comment and assert can probably be removed (same for the similar comment/assert in TypeArrayKlass::oop_oop_iterate_impl(). Could be a left-over from a time when we had to deal with OM and/or stack-locks in the header. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751527745 From dholmes at openjdk.org Tue Sep 10 08:54:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Sep 2024 08:54:13 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 This seems trivially fine to me. The JEP isn't really relevant for this C code as we have C99 as a minimum for a while now. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20909#pullrequestreview-2291801397 From mli at openjdk.org Tue Sep 10 08:54:13 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 10 Sep 2024 08:54:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com> References: <6I0T4rOjOTj-FZxpspatEo6j1_Num75bCAOBNxsrHI8=.097f731e-7c92-4eac-a379-c2df336cd412@github.com> Message-ID: On Mon, 9 Sep 2024 14:08:53 GMT, Roman Kennke wrote: >> Yes, I'm interested in it. Thanks for raising the discussion. :) > > If anybody is doing it, please send me a patch, or we can do it as a follow-up PR. Thanks. I'll send it to you if I finish it in time, otherwise I will do it in a separate pr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751544394 From jwaters at openjdk.org Tue Sep 10 09:05:10 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 10 Sep 2024 09:05:10 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:51:56 GMT, David Holmes wrote: > This seems trivially fine to me. The JEP isn't really relevant for this C code as we have C99 as a minimum for a while now. > > Thanks We actually have C11 as a minimum, C99 for Unix and C89 for Windows was our old standard, but that has since changed ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340086782 From dholmes at openjdk.org Tue Sep 10 09:14:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 10 Sep 2024 09:14:11 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: <_3Rjp678JLW7L-IYTVij3Trz4bax7oDxJCM5Kil4oHk=.0e43bcca-0b6c-48b4-80e7-409b1ffe8420@github.com> On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 Yes I misspoke, I should have said we have required at least C99 for a while now. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340105221 From rkennke at openjdk.org Tue Sep 10 09:31:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 09:31:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Tue, 10 Sep 2024 08:37:43 GMT, Roman Kennke wrote: >>> could be any value that is not a valid field offset >> >> I understand that that "random value" needs to satisfy this condition. > > With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though. > (Fwiw, the method is also used during Universe initialization). Yes, but only in the -UCOH branch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751604467 From stefank at openjdk.org Tue Sep 10 10:05:10 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 10 Sep 2024 10:05:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Tue, 10 Sep 2024 08:41:16 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/objArrayKlass.inline.hpp line 74: >> >>> 72: void ObjArrayKlass::oop_oop_iterate(oop obj, OopClosureType* closure) { >>> 73: // In this assert, we cannot safely access the Klass* with compact headers. >>> 74: assert (UseCompactObjectHeaders || obj->is_array(), "obj must be array"); >> >> If we can't safely access the `Klass*` here, why is the call to `obj->klass()` below safe? > > Good question. This comment and assert can probably be removed (same for the similar comment/assert in TypeArrayKlass::oop_oop_iterate_impl(). Could be a left-over from a time when we had to deal with OM and/or stack-locks in the header. FWIW, I've been running tests with this assert restored (and the one in TypeArrayKlass) without hitting any problems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751656595 From rkennke at openjdk.org Tue Sep 10 11:29:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 11:29:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> Message-ID: On Tue, 10 Sep 2024 07:53:23 GMT, Roman Kennke wrote: >> src/hotspot/share/gc/shared/collectedHeap.cpp line 232: >> >>> 230: } >>> 231: >>> 232: // With compact headers, we can't safely access the class, due >> >> Suggestion: >> >> // With compact headers, we can't safely access the klass, due >> >> >> This is the case why? Because we might not have copied the header yet? Is this method actually ever used while the forwarded object is unstable? >> Given this is used for verification only afaik, we should make an effort to provide that check. > > With compact headers, we can't safely access the Klass* when the object has been forwarded, because non-full-GC-forwarding temporarily overwrites the mark-word, and thus the Klass*, with the forwarding pointer, and here we have no way to make a distinction between Full-GC and regular GC forwarding. > > I improved the code to make the check when the object is not forwarded. Not sure if we could/should do more (e.g. pass around is_full argument to make the distinction, or find the - possibly few - places where we might call is_oop() on from-space objects in regular GC and do the check in a forwardee-safe way?). Ah, I found it! It seems only the ShenandoahVerifier calls oop_iterate() on from_space objects, which can have a forwarding, which would mess with the object's Klass*. We're lucky because that iterator doesn't visit the Klass*. I see the following ways out: - The caller must ensure that the oop is ok and Klass* is accessible. I could do that in the ShenandoahVerifier. It kinda defeats the point, though, we want the verifier operate on the 'raw' object, not necessarily the forwardee. - Next easy way out would be to use 'this' instead of obj->klass(). Should makes sense, because it should always be the same. Using 'this' in the assert (this->is_array_klass()) is kinda bogus, though. And asserting (this == obj->klass()) would be nice, but would have the same problem as before where we would need to exclude UCOH for the case where Shenandoah needs it. In-fact, this is done already in oopDesc::oop_iterate_backwards(), but also excluding UCOH. - We could add a hook in the iterator that gives the Klass* for a given oop, which can then be overridden by the actual iterator to do the right thing, e.g. load the Klass* from the forwardee. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751770293 From djelinski at openjdk.org Tue Sep 10 11:36:10 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 10 Sep 2024 11:36:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c make/modules/java.base/Lib.gmk line 48: > 46: OPTIMIZATION := LOW, \ > 47: EXTRA_HEADER_DIRS := \ > 48: libjava/nio/ch, \ This appears to be unneeded make/modules/java.base/Lib.gmk line 81: > 79: libjava/nio/ch \ > 80: libnio/ch \ > 81: libnio/fs \ libnio/fs is gone on all platforms other than aix; is this still necessary? make/modules/java.base/lib/CoreLibraries.gmk line 71: > 69: -framework Foundation \ > 70: -framework SystemConfiguration, \ > 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: > 573: * Used to trigger loading of native libraries > 574: */ > 575: public static void load() { } do we still need this method? src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2: > 1: /* > 2: * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved. No changes in this file src/java.base/unix/native/libnio/ch/NIOUtil.c line 34: > 32: #include "jvm.h" > 33: #include "jlong.h" > 34: #include "sun_nio_ch_IOUtil.h" should this be NIOUtil? src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: > 1095: > 1096: static { > 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); ...do we still need net here? src/java.base/windows/native/libnio/ch/NIOUtil.c line 41: > 39: > 40: JNIEXPORT jboolean JNICALL > 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed unused ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751645238 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751648219 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751651925 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751744295 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751746774 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751766398 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751770939 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751774903 From stuefe at openjdk.org Tue Sep 10 12:07:09 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Sep 2024 12:07:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 15:49:57 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/compressedKlass.cpp line 214: > >> 212: ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)", >> 213: len, max_encoding_range_size()); >> 214: vm_exit_during_initialization(ss.base()); > > Why does this exit and not turn off compressed klass pointers and compact object headers? This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751819814 From stuefe at openjdk.org Tue Sep 10 12:16:11 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Sep 2024 12:16:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 15:50:50 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/compressedKlass.cpp line 222: > >> 220: return; >> 221: } >> 222: #endif > > Why not add null pd_initialize to zero to remove this conditional code? I can do that. Added to backlist (https://wiki.openjdk.org/display/lilliput/JEP-450+Review+Todo) > src/hotspot/share/oops/compressedKlass.cpp line 224: > >> 222: #endif >> 223: >> 224: if (tiny_classpointer_mode()) { > > I kind of agree with Thomas Schatzl for this. Maybe it should be compact_classpointer_mode(). It's nice to have a new string for grep, but they're not really that tiny. Yes, makes sense. Added to backlist. This coding was developed somewhat independently from +COH at the beginning, but now the two parts (tinycp and the rest of COH) depend on each other anyway. I should just use UseCompactObjectHeaders or a flag directly derived from it. > src/hotspot/share/oops/compressedKlass.cpp line 234: > >> 232: _range = len; >> 233: >> 234: constexpr int log_cacheline = 6; > > Is 6 the log of DEFAULT_CACHE_LINE_SIZE? 64, yes > src/hotspot/share/oops/compressedKlass.cpp line 243: > >> 241: } else { >> 242: >> 243: // In legacy mode, we try, in order of preference: > > Can you not use the word 'legacy' here? Maybe in "non-compact object header mode"... okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751828214 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751831035 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751831994 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751833034 From coleenp at openjdk.org Tue Sep 10 12:22:09 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Sep 2024 12:22:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:03:59 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 214: >> >>> 212: ss.print("Class space size (%zu) exceeds the maximum possible size (%zu)", >>> 213: len, max_encoding_range_size()); >>> 214: vm_exit_during_initialization(ss.base()); >> >> Why does this exit and not turn off compressed klass pointers and compact object headers? > > This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. > > Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too. Ok, in this case, that's fine if we already asserted. A fatal error is better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751840556 From rkennke at openjdk.org Tue Sep 10 12:42:48 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 12:42:48 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v10] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: - More touch-ups, fix Shenandoah oop iterator - Remove asserts in XArrayKlass::oop_oop_iterate() - Various touch-ups - Improve is_oop() - Rename GCForwarding -> FullGCForwarding; some touch-ups - Fix comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/2884499a..5da250cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=08-09 Stats: 238 lines in 36 files changed: 74 ins; 65 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Tue Sep 10 12:42:49 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Sep 2024 12:42:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v10] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Mon, 9 Sep 2024 15:59:43 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: >> >> - More touch-ups, fix Shenandoah oop iterator >> - Remove asserts in XArrayKlass::oop_oop_iterate() >> - Various touch-ups >> - Improve is_oop() >> - Rename GCForwarding -> FullGCForwarding; some touch-ups >> - Fix comment > > src/hotspot/share/oops/compressedKlass.cpp line 116: > >> 114: _range = end - _base; >> 115: >> 116: DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);) > > Can you refactor so the aarch64 path runs this same code without duplication? In tinycp mode, aarch64 runs this code though? The aarch64 variant of pd_initialize just returns then. In non-COH mode (preexisting, not touched by this patch) Aarch64 needs its own handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751866773 From stuefe at openjdk.org Tue Sep 10 12:42:49 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Sep 2024 12:42:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com> References: <86SISXYdKqHq5_nSqeVVNgmxplVK6QuHvOjCmiCKkzQ=.92ac6af1-9a94-4068-b625-1e331314826e@github.com> <4cTKmlYUEtFpr2TURf25gd7-_eSb-uF0cC0BmLl6wd0=.b9f0482d-5439-421b-9a29-7a014fb72558@github.com> Message-ID: On Mon, 9 Sep 2024 16:01:10 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/compressedKlass.hpp line 43: >> >>> 41: >>> 42: // Tiny-class-pointer mode >>> 43: static int _tiny_cp; // -1, 0=true, 1=false >> >> Suggestion: >> >> static int _tiny_cp; // -1 = uninitialized, 0 = true, 1 = false >> >> In addition to that, I am not sure if introducing a new term ("tiny") for compact class header related changes (and just here) makes the code more clear; I would have expected a "_compact_" prefix. Also all other members use "k"-klass and spell out "klass pointer", so I would prefer to keep that style. > > I agree with this. 'cp' reads as ConstantPool for me even though this is a different context. Okay, I will change that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751867998 From syan at openjdk.org Tue Sep 10 12:45:08 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 10 Sep 2024 12:45:08 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 Thanks all for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340620724 From duke at openjdk.org Tue Sep 10 12:45:08 2024 From: duke at openjdk.org (duke) Date: Tue, 10 Sep 2024 12:45:08 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 @sendaoYan Your change (at version bf2ceae0fc34a21760414472805c0bda5ca4a3db) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2340629392 From ihse at openjdk.org Tue Sep 10 13:33:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 10 Sep 2024 13:33:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 09:56:26 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > make/modules/java.base/Lib.gmk line 81: > >> 79: libjava/nio/ch \ >> 80: libnio/ch \ >> 81: libnio/fs \ > > libnio/fs is gone on all platforms other than aix; is this still necessary? We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I ` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course. > make/modules/java.base/lib/CoreLibraries.gmk line 71: > >> 69: -framework Foundation \ >> 70: -framework SystemConfiguration, \ >> 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ > > Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751967809 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751975461 From jeisl at openjdk.org Tue Sep 10 13:54:23 2024 From: jeisl at openjdk.org (Josef Eisl) Date: Tue, 10 Sep 2024 13:54:23 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> Message-ID: <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com> On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote: >> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not. >> >> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. >> >> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also update build to link properly src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135: > 133: #endif > 134: > 135: if (!JVM_IsStaticallyLinked()) { These "cross-library" link-type probes are a challenge for GraalVM native image. In native image, we statically link most standard JNI libraries into the final executable. However in some cases, for example AWT, static linking is not feasible due to their dependencies. Thus, we resort to dynamic linking. Have a mix of static and dynamic linking means that `JVM_IsStaticallyLinked` should give different answers based on the caller. Example: lets assume a follow-up change introduces a call to `JVM_IsStaticallyLinked` in libnet (which native image statically links): * if `JVM_IsStaticallyLinked` is called from libawt.so, we want to answer `false` * if `JVM_IsStaticallyLinked` is called from libnet.a, we want to answer `true` Is the mixed linking use case is something that the Hermetic Java effort is having on its radar? For this particular case, one solutions could be to avoid cross-library calls. I.e., instead of calling `JVM_IsStaticallyLinked`, have an `AWT_IsStaticallyLinked` that is local to the libawt. This is similar to the pattern also used for JLI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1752023584 From djelinski at openjdk.org Tue Sep 10 15:18:09 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 10 Sep 2024 15:18:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 13:30:05 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/lib/CoreLibraries.gmk line 71: >> >>> 69: -framework Foundation \ >>> 70: -framework SystemConfiguration, \ >>> 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \ >> >> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms. > > I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752181579 From rkennke at openjdk.org Tue Sep 10 19:11:30 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 10 Sep 2024 19:11:30 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix FullGCForwarding initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/5da250cf..6abda7bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=09-10 Stats: 8 lines in 7 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Tue Sep 10 19:11:30 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 10 Sep 2024 19:11:30 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 17:40:03 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/compressedKlass.inline.hpp line 100: > >> 98: check_valid_klass(k, base(), shift()); >> 99: // Also assert that k falls into what we know is the valid Klass range. This is usually smaller >> 100: // than the encoding range (e.g. encoding range covers 4G, but we only have 1G class space and a > > 1G is the default CompressedClassSpaceSize but can be larger, right? So the comment isn't quite accurate. Or with tiny class pointers can it only be 1G? The comment was misleading, it referred to the 1g default class space. I recently changed class space (in mainline) to be max. 4GB (minus whatever little CDS needs), and for +COH, this is still true. 22 bit class pointer and 10 bit shift still gives us a max encoding range size of 4GB. I will update the comment. (->backlist) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1751872461 From naoto at openjdk.org Tue Sep 10 19:50:13 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 10 Sep 2024 19:50:13 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files Message-ID: This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/20940/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339803 Stats: 41 lines in 4 files changed: 7 ins; 4 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/20940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20940/head:pull/20940 PR: https://git.openjdk.org/jdk/pull/20940 From bpb at openjdk.org Tue Sep 10 19:58:48 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Sep 2024 19:58:48 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v6] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c - Merge - 8337143: Removed dependency of libjava on headers in libnio/ch - 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05 Stats: 1561 lines in 90 files changed: 771 ins; 674 del; 116 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Tue Sep 10 20:01:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 10 Sep 2024 20:01:14 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: > >> 573: * Used to trigger loading of native libraries >> 574: */ >> 575: public static void load() { } > > do we still need this method? Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752651246 From ihse at openjdk.org Tue Sep 10 21:45:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 10 Sep 2024 21:45:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 15:15:26 GMT, Daniel Jeli?ski wrote: >> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113). > > well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752762279 From ihse at openjdk.org Tue Sep 10 21:50:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 10 Sep 2024 21:50:14 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com> References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com> Message-ID: On Tue, 10 Sep 2024 13:51:55 GMT, Josef Eisl wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update build to link properly > > src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135: > >> 133: #endif >> 134: >> 135: if (!JVM_IsStaticallyLinked()) { > > These "cross-library" link-type probes are a challenge for GraalVM native image. In native image, we statically link most standard JNI libraries into the final executable. However in some cases, for example AWT, static linking is not feasible due to their dependencies. Thus, we resort to dynamic linking. Have a mix of static and dynamic linking means that `JVM_IsStaticallyLinked` should give different answers based on the caller. Example: > lets assume a follow-up change introduces a call to `JVM_IsStaticallyLinked` in libnet (which native image statically links): > * if `JVM_IsStaticallyLinked` is called from libawt.so, we want to answer `false` > * if `JVM_IsStaticallyLinked` is called from libnet.a, we want to answer `true` > > Is the mixed linking use case is something that the Hermetic Java effort is having on its radar? > > For this particular case, one solutions could be to avoid cross-library calls. I.e., instead of calling `JVM_IsStaticallyLinked`, have an `AWT_IsStaticallyLinked` that is local to the libawt. This is similar to the pattern also used for JLI. Mixing static and dynamic libraries willy-nilly sounds like a situation that is hard to resolve in a safe and sound way. The basic assumption here has been that you either have all libraries dynamic, or all libraries static. In the particular case you mention about libawt, I think the proper solution is to sort out the mess that is libawt_headless/libawt_xawt. It seems to me that the X support should be loaded using dlopen, not by hard dependencies to the X libraries. I think that should solve your problem (as well as many other problems). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1752767100 From jlu at openjdk.org Tue Sep 10 22:20:07 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 10 Sep 2024 22:20:07 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files In-Reply-To: References: Message-ID: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com> On Tue, 10 Sep 2024 19:45:01 GMT, Naoto Sato wrote: > This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375: > 1373: Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS) > 1374: .filter(p -> p.toFile().isFile()) > 1375: .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica")) I am just curious, why is this needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752828774 From naoto at openjdk.org Tue Sep 10 22:42:37 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 10 Sep 2024 22:42:37 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: > This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: tz files aligned with the default TzdbZoneRulesProvider list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20940/files - new: https://git.openjdk.org/jdk/pull/20940/files/264d5772..423720c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20940&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20940.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20940/head:pull/20940 PR: https://git.openjdk.org/jdk/pull/20940 From naoto at openjdk.org Tue Sep 10 22:42:37 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 10 Sep 2024 22:42:37 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com> References: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com> Message-ID: On Tue, 10 Sep 2024 22:17:51 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> tz files aligned with the default TzdbZoneRulesProvider list > > make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375: > >> 1373: Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS) >> 1374: .filter(p -> p.toFile().isFile()) >> 1375: .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica")) > > I am just curious, why is this needed? It would otherwise scan all files under the directory, and fails with `iso3166.tab` or `zone.tab`, which include "LI" as the country code at the beginning of the line, that interfere with "Link" match. Having said that, the default list was different from the one in `TzdbZoneRulesProvider`. I removed extra file names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752889391 From jlu at openjdk.org Tue Sep 10 22:56:05 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 10 Sep 2024 22:56:05 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato wrote: >> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > tz files aligned with the default TzdbZoneRulesProvider list Looks good to me ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/20940#pullrequestreview-2294103087 From jlu at openjdk.org Tue Sep 10 22:56:06 2024 From: jlu at openjdk.org (Justin Lu) Date: Tue, 10 Sep 2024 22:56:06 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: <18Xkg25L-LmhrdCcjMdCzJubQ9ZVEp77eZTWgX-yVpg=.01e02c1e-4e19-4d6f-bf90-1fec03b6e84f@github.com> Message-ID: On Tue, 10 Sep 2024 22:39:38 GMT, Naoto Sato wrote: >> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1375: >> >>> 1373: Files.walk(Path.of(tzDataDir), 1, FileVisitOption.FOLLOW_LINKS) >>> 1374: .filter(p -> p.toFile().isFile()) >>> 1375: .filter(p -> p.getFileName().toString().matches("africa|antarctica|asia|australasia|backward|backzone|etcetera|europe|factory|northamerica|southamerica")) >> >> I am just curious, why is this needed? > > It would otherwise scan all files under the directory, and fails with `iso3166.tab` or `zone.tab`, which include "LI" as the country code at the beginning of the line, that interfere with "Link" match. > Having said that, the default list was different from the one in `TzdbZoneRulesProvider`. I removed extra file names. Right, the match in general is much more lenient now, so need to restrict the files searched for false positives. Thanks for the explanation, that makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1752897921 From naoto at openjdk.org Tue Sep 10 23:15:04 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 10 Sep 2024 23:15:04 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 22:53:15 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> tz files aligned with the default TzdbZoneRulesProvider list > > Looks good to me Thanks, @justin-curtis-lu. @coffeys, would you please review this PR, which can also apply to the tzupdater tool? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2342318673 From syan at openjdk.org Wed Sep 11 02:15:14 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 11 Sep 2024 02:15:14 GMT Subject: Integrated: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 This pull request has now been integrated. Changeset: a6faf824 Author: SendaoYan Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/a6faf8247b58d73dca199fe1e8b0e914c415f67f Stats: 14 lines in 2 files changed: 1 ins; 12 del; 1 mod 8339714: Delete tedious bool type define Reviewed-by: jwaters, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/20909 From syan at openjdk.org Wed Sep 11 02:30:10 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 11 Sep 2024 02:30:10 GMT Subject: RFR: 8339714: Delete tedious bool type define In-Reply-To: References: Message-ID: <6wPZ40cgyH7U6kJN31R80qymYXzQwTX-ndD-2MKboo0=.9178e030-415a-4b5d-8e13-a298e03e9c4f@github.com> On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote: > Hi all, > This PR delete tedious bool type define in `src/java.base/unix/native/libjsig/jsig.c` and `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we can "#include " to use bool type directly, like [string.h](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/libpipewire/include/spa/utils/string.h#L13) do. > Make code more concision, the risk is quite low. > > Additional testing: > > - [x] Local build with --with-hsdis=binutils --with-binutils=$HOME/software/binutils > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux x64 > - [x] Jtreg tests(include tier1/tier2/tier3 etc.) on linux aarch64 Thanks for the sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20909#issuecomment-2342489060 From djelinski at openjdk.org Wed Sep 11 06:03:08 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 06:03:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 21:42:08 GMT, Magnus Ihse Bursie wrote: >> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed. > > And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1753167982 From jeisl at openjdk.org Wed Sep 11 07:05:17 2024 From: jeisl at openjdk.org (Josef Eisl) Date: Wed, 11 Sep 2024 07:05:17 GMT Subject: RFR: 8338768: Introduce runtime lookup to check for static builds [v2] In-Reply-To: References: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com> <1xFVXOUr023IxIHucx0v8dket_QOWsIV0G3wVHnF5aE=.23e8334b-a4ed-4d94-8ad9-376ffe043882@github.com> Message-ID: On Tue, 10 Sep 2024 21:47:15 GMT, Magnus Ihse Bursie wrote: > sort out the mess that is libawt_headless/libawt_xawt sounds good. can you point me to a JBS? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1753307449 From epeter at openjdk.org Wed Sep 11 08:28:13 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 11 Sep 2024 08:28:13 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix FullGCForwarding initialization @rkennke Can you please explain the changes in these tests: test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2342983487 From rkennke at openjdk.org Wed Sep 11 13:37:16 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 11 Sep 2024 13:37:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 08:24:16 GMT, Emanuel Peter wrote: > @rkennke Can you please explain the changes in these tests: > > ``` > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > ``` > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2343693629 From jsjolen at openjdk.org Wed Sep 11 14:00:17 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 11 Sep 2024 14:00:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix FullGCForwarding initialization Hi, Me and @caspernorrbin are reviewing the Metaspace changes (so anything in the `memory` and `metaspace` folders). We have found minor improvements that can be made and some nits, but the code over all looks OK. We are finishing up a first round of review now, and will have a second one. Thank you for your hard work and your patience with the review process. src/hotspot/share/memory/classLoaderMetaspace.cpp line 87: > 85: klass_alignment_words, > 86: "class arena"); > 87: } As per my comment in the header file, change the code to this: ```c++ if (class_context != nullptr) { // ... Same as in PR } else { _class_space_arena = _non_class_space_arena; } src/hotspot/share/memory/classLoaderMetaspace.cpp line 115: > 113: if (wastage.is_nonempty()) { > 114: non_class_space_arena()->deallocate(wastage); > 115: } This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example: ```c++ // Any wasted memory is presumably too small for any class. // Therefore, give it back to the non-class space arena's free list. src/hotspot/share/memory/classLoaderMetaspace.cpp line 118: > 116: #ifdef ASSERT > 117: if (result.is_nonempty()) { > 118: const bool in_class_arena = class_space_arena() != nullptr ? class_space_arena()->contains(result) : false; Unnecessary nullptr check if you take my suggestion, or you should switch to `have_class_space_arena`. src/hotspot/share/memory/classLoaderMetaspace.cpp line 165: > 163: MetaBlock bl(ptr, word_size); > 164: // If the block would be reusable for a Klass, add to class arena, otherwise to > 165: // then non-class arena. Nit: spelling, "the" src/hotspot/share/memory/classLoaderMetaspace.hpp line 81: > 79: metaspace::MetaspaceArena* class_space_arena() const { return _class_space_arena; } > 80: > 81: bool have_class_space_arena() const { return _class_space_arena != nullptr; } This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers` src/hotspot/share/memory/metaspace.cpp line 656: > 654: // Adjust size of the compressed class space. > 655: > 656: const size_t res_align = reserve_alignment(); Can you change the name to `root_chunk_size`? src/hotspot/share/memory/metaspace.hpp line 112: > 110: static size_t max_allocation_word_size(); > 111: > 112: // Minimum allocation alignment, in bytes. All MetaData shall be aligned correclty Nit: Spelling, "correctly" src/hotspot/share/memory/metaspace/metablock.hpp line 48: > 46: > 47: MetaWord* base() const { return _base; } > 48: const MetaWord* end() const { return _base + _word_size; } `assert(is_nonempty())` src/hotspot/share/memory/metaspace/metablock.hpp line 51: > 49: size_t word_size() const { return _word_size; } > 50: bool is_empty() const { return _base == nullptr; } > 51: bool is_nonempty() const { return _base != nullptr; } Can `_base == nullptr` but `_word_size != 0`? src/hotspot/share/memory/metaspace/metablock.hpp line 52: > 50: bool is_empty() const { return _base == nullptr; } > 51: bool is_nonempty() const { return _base != nullptr; } > 52: void reset() { _base = nullptr; _word_size = 0; } Is this function really necessary? According to my IDE it's only used in tests and even then the `MetaBlock` isn't used afterwards (so it has no effect). src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 44: > 42: class FreeBlocks; > 43: > 44: struct ArenaStats; Nit: Sort? src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 84: > 82: // between threads and needs to be synchronized in CLMS. > 83: > 84: const size_t _allocation_alignment_words; Nit: Document this? All other members are documented. ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2296528491 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754335269 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754398993 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754343513 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754459464 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754330432 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754619023 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754508321 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754142822 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754142098 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754153662 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754192464 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754197251 From epeter at openjdk.org Wed Sep 11 14:17:16 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 11 Sep 2024 14:17:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 13:34:28 GMT, Roman Kennke wrote: > > @rkennke Can you please explain the changes in these tests: > > ``` > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > > ``` > > > > > > > > > > > > > > > > > > > > > > > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). > > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. > > I will re-evaluate those tests, and add comments or remove the restrictions. If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;) My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2343797957 From rcastanedalo at openjdk.org Wed Sep 11 14:17:17 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 11 Sep 2024 14:17:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix FullGCForwarding initialization src/hotspot/share/memory/metaspace/binList.hpp line 202: > 200: b_last = b; > 201: } > 202: if (UseNewCode)printf("\n"); I guess this line is a leftover to be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754702742 From rcastanedalo at openjdk.org Wed Sep 11 14:50:17 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 11 Sep 2024 14:50:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 19:11:30 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix FullGCForwarding initialization src/hotspot/share/opto/machnode.cpp line 390: > 388: t = t->make_ptr(); > 389: } > 390: if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) { Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1754813751 From coffeys at openjdk.org Wed Sep 11 15:16:08 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 11 Sep 2024 15:16:08 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato wrote: >> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > tz files aligned with the default TzdbZoneRulesProvider list LGTM `sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2343959123 From stuefe at openjdk.org Wed Sep 11 16:17:16 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 11 Sep 2024 16:17:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 12:47:30 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/classLoaderMetaspace.cpp line 115: > >> 113: if (wastage.is_nonempty()) { >> 114: non_class_space_arena()->deallocate(wastage); >> 115: } > > This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example: > > ```c++ > // Any wasted memory is presumably too small for any class. > // Therefore, give it back to the non-class space arena's free list. Yes. Some background: - wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert) - wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small Yes, I will write a better comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755111131 From stuefe at openjdk.org Wed Sep 11 16:17:16 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 11 Sep 2024 16:17:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 14:15:12 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/metaspace/binList.hpp line 202: > >> 200: b_last = b; >> 201: } >> 202: if (UseNewCode)printf("\n"); > > I guess this line is a leftover to be removed? Yep thanks for spotting ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755115905 From stuefe at openjdk.org Wed Sep 11 16:17:17 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 11 Sep 2024 16:17:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 16:14:39 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/binList.hpp line 202: >> >>> 200: b_last = b; >>> 201: } >>> 202: if (UseNewCode)printf("\n"); >> >> I guess this line is a leftover to be removed? > > Yep thanks for spotting So that was causing the empty lines in my logs (facepalm) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1755116656 From naoto at openjdk.org Wed Sep 11 16:25:05 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 11 Sep 2024 16:25:05 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 15:13:25 GMT, Sean Coffey wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> tz files aligned with the default TzdbZoneRulesProvider list > > LGTM > > `sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir) Thanks, @coffeys > `sun/util/calendar/zi/TestZoneInfo310.java` exercises the tzdb compiler. I wonder if it's worth adding some dummy rules which test the new leniency added to the compiler ? (perhaps even just to the jdk11_backward file included in the test dir) IIUC the purpose of that test is to check the integrity of `tzdb.dat` which is created at the JDK build time, with the pre-310 era javazic. So adding extra tz files at the test time would break (because `tzdb.dat` do not include that lenient test tz file). Testing of JDK build tool is hard IMO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2344111564 From bpb at openjdk.org Wed Sep 11 16:36:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 16:36:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeli?ski wrote: >> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`? > > Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. >From a clean build in the CI with `mswsock.lib` removed: [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755143206 From djelinski at openjdk.org Wed Sep 11 16:51:08 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 16:51:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Wed, 11 Sep 2024 16:33:28 GMT, Brian Burkhalter wrote: >> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`. > > From a clean build in the CI with `mswsock.lib` removed: > > > [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol > TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). There's no FileDispatcherImpl.obj in libnio. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755161852 From djelinski at openjdk.org Wed Sep 11 16:54:07 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Sep 2024 16:54:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> On Tue, 10 Sep 2024 19:58:45 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575: >> >>> 573: * Used to trigger loading of native libraries >>> 574: */ >>> 575: public static void load() { } >> >> do we still need this method? > > Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. that's a good point. The comment might need to be updated to reflect that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755166228 From rkennke at openjdk.org Wed Sep 11 17:31:54 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 11 Sep 2024 17:31:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v12] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Make is_oop() MT-safe - Re-enable some vectorization tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/6abda7bc..b6c11f74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=10-11 Stats: 32 lines in 6 files changed: 7 ins; 8 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Wed Sep 11 17:38:57 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 11 Sep 2024 17:38:57 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: Message-ID: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Revert accidental change of UCOH default ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/b6c11f74..9e008ac1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From coffeys at openjdk.org Wed Sep 11 18:37:05 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 11 Sep 2024 18:37:05 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato wrote: >> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > tz files aligned with the default TzdbZoneRulesProvider list ah yes, it's the other way around then (java zi compiler creating legacy data to match JSR 310 data) - ok, impossible to test then.. outside of setting up a build test env. maybe you can verify with a few simple edits to a tzdata file and building. ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20940#pullrequestreview-2298211125 From bpb at openjdk.org Wed Sep 11 19:21:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:21:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeli?ski wrote: >> From a clean build in the CI with `mswsock.lib` removed: >> >> >> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol >> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0 > > did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). > There's no FileDispatcherImpl.obj in libnio. Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755434973 From bpb at openjdk.org Wed Sep 11 19:25:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:25:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: > >> 1095: >> 1096: static { >> 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); > > ...do we still need net here? We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755440401 From naoto at openjdk.org Wed Sep 11 19:30:12 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 11 Sep 2024 19:30:12 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 18:33:59 GMT, Sean Coffey wrote: > maybe you can verify with a few simple edits to a tzdata file and building Yes, that is exactly what I did for this testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20940#issuecomment-2344538481 From naoto at openjdk.org Wed Sep 11 19:30:13 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 11 Sep 2024 19:30:13 GMT Subject: Integrated: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 19:45:01 GMT, Naoto Sato wrote: > This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. This pull request has now been integrated. Changeset: 35a94b76 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/35a94b769761bd923fe6db03be672f05c1a74c38 Stats: 41 lines in 4 files changed: 7 ins; 4 del; 30 mod 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files Reviewed-by: jlu, coffeys ------------- PR: https://git.openjdk.org/jdk/pull/20940 From ihse at openjdk.org Wed Sep 11 19:34:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 11 Sep 2024 19:34:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> Message-ID: On Wed, 11 Sep 2024 19:18:18 GMT, Brian Burkhalter wrote: >> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89). >> There's no FileDispatcherImpl.obj in libnio. > > Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755463756 From bpb at openjdk.org Wed Sep 11 19:34:07 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 11 Sep 2024 19:34:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> Message-ID: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote: >> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent. > > Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. > > Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? I've re-checked it and am running a CI job and will check it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755467953 From coleenp at openjdk.org Wed Sep 11 21:18:12 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Sep 2024 21:18:12 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert accidental change of UCOH default I was starting to understand the concerns with having prototype_header in Klass. It seems like it would simplify encoding the klass for object allocation. My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this. You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor. diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp index fd198f54fc9..7aa4bd24948 100644 --- a/src/hotspot/share/oops/instanceKlass.cpp +++ b/src/hotspot/share/oops/instanceKlass.cpp @@ -511,7 +511,7 @@ InstanceKlass::InstanceKlass() { } InstanceKlass::InstanceKlass(const ClassFileParser& parser, KlassKind kind, ReferenceType reference_type) : - Klass(kind), + Klass(kind, (!parser.is_interface() && !parser.is_abstract())), _nest_members(nullptr), _nest_host(nullptr), _permitted_subclasses(nullptr), ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2344715540 From bpb at openjdk.org Thu Sep 12 02:10:00 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:00 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: Message-ID: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8337143: Clean up to address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/4f47d5a6..853d3491 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05-06 Stats: 20 lines in 9 files changed: 4 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > > make/modules/java.base/Lib.gmk line 48: > >> 46: OPTIMIZATION := LOW, \ >> 47: EXTRA_HEADER_DIRS := \ >> 48: libjava/nio/ch, \ > > This appears to be unneeded Agreed. See 853d349. > src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2: > >> 1: /* >> 2: * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved. > > No changes in this file There is one now. 853d349 > src/java.base/unix/native/libnio/ch/NIOUtil.c line 34: > >> 32: #include "jvm.h" >> 33: #include "jlong.h" >> 34: #include "sun_nio_ch_IOUtil.h" > > should this be NIOUtil? Yes. See 853d349. > src/java.base/windows/native/libnio/ch/NIOUtil.c line 41: > >> 39: >> 40: JNIEXPORT jboolean JNICALL >> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed > > unused Removed. 853d349 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983126 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984164 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984274 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755985066 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> Message-ID: On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/Lib.gmk line 81: >> >>> 79: libjava/nio/ch \ >>> 80: libnio/ch \ >>> 81: libnio/fs \ >> >> libnio/fs is gone on all platforms other than aix; is this still necessary? > > We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I ` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course. Not changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983319 From bpb at openjdk.org Thu Sep 12 02:10:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:02 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com> <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com> Message-ID: <8iOw1S8wQQ6G7-laGTbkZI5rnQjOZrbqv0iZ9BmThTY=.4baaded4-c285-45a2-83c1-d0fd7f3e7ef3@github.com> On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote: >> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down. >> >> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio? > > I've re-checked it and am running a CI job and will check it again. Re-tests passed. See 853d349. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983781 From bpb at openjdk.org Thu Sep 12 02:10:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:03 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com> Message-ID: On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeli?ski wrote: >> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions. > > that's a good point. The comment might need to be updated to reflect that. Comments added in 853d349. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983974 From bpb at openjdk.org Thu Sep 12 02:10:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 02:10:03 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> Message-ID: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote: >> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097: >> >>> 1095: >>> 1096: static { >>> 1097: jdk.internal.loader.BootLoader.loadLibrary("net"); >> >> ...do we still need net here? > > We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. Moved to `NTLMAuthentication` static initializer. 853d349 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984949 From djelinski at openjdk.org Thu Sep 12 06:27:09 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Sep 2024 06:27:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Clean up to address reviewer comments Thanks for making the changes. LGTM, assuming that tests still pass. One question in line. src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221: > 219: static futimesat_func* my_futimesat_func = NULL; > 220: static futimens_func* my_futimens_func = NULL; > 221: #ifndef _ALLBSD_SOURCE This change looks unrelated. Was it intentional? ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2299319884 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1756202839 From rcastanedalo at openjdk.org Thu Sep 12 10:20:15 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 12 Sep 2024 10:20:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert accidental change of UCOH default src/hotspot/share/opto/lcm.cpp line 272: > 270: const TypePtr* tptr; > 271: if ((UseCompressedOops || UseCompressedClassPointers) && > 272: (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) { Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled: (!UseCompressedOops, UseCompressedClassPointers, CompressedKlassPointers::shift() != 0) ( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1756570168 From rcastanedalo at openjdk.org Thu Sep 12 11:49:15 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 12 Sep 2024 11:49:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Wed, 11 Sep 2024 17:38:57 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert accidental change of UCOH default src/hotspot/share/cds/filemap.cpp line 2457: > 2455: compressed_oops(), compressed_class_pointers()); > 2456: if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) { > 2457: log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is " The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1756699774 From rkennke at openjdk.org Thu Sep 12 13:16:14 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 12 Sep 2024 13:16:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 13:34:28 GMT, Roman Kennke wrote: >> @rkennke Can you please explain the changes in these tests: >> >> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java >> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java >> >> >> You added these IR rule restriction: >> `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` >> >> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. >> >> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? >> >> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. >> >> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). > >> @rkennke Can you please explain the changes in these tests: >> >> ``` >> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java >> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java >> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java >> ``` >> >> You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` >> >> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. >> >> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? >> >> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. >> >> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). > > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. > > I will re-evaluate those tests, and add comments or remove the restrictions. > > > @rkennke Can you please explain the changes in these tests: > > > ``` > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` > > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. > > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? > > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. > > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). > > > > > > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. > > I will re-evaluate those tests, and add comments or remove the restrictions. > > If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;) > > My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization. Indeed, I could re-enable all tests in: test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java but unfortunately not those others: > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset. I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2346250313 From epeter at openjdk.org Thu Sep 12 13:23:14 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 12 Sep 2024 13:23:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 13:13:01 GMT, Roman Kennke wrote: > > > > @rkennke Can you please explain the changes in these tests: > > > > ``` > > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > > > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` > > > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. > > > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? > > > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. > > > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). > > > > > > > > > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. > > > I will re-evaluate those tests, and add comments or remove the restrictions. > > > > > > If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ;) > > My suggestion is this: go over the examples, check which ones are now ok. Those that are not ok, add a comment, and file a bug: I can then analyze those cases later, and see how to write other tests or improve auto-vectorization. > > Indeed, I could re-enable all tests in: > > ``` > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > ``` > > but unfortunately not those others: > > ``` > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > ``` > > I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset. > > I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it. Excellent, that is what I hoped for! Thanks for filing the bug, I'll look into it once this is integrated. You should probably mark it as "blocked by", not "related to" ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2346266568 From stuefe at openjdk.org Thu Sep 12 15:41:22 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Sep 2024 15:41:22 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Thu, 12 Sep 2024 10:17:47 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert accidental change of UCOH default > > src/hotspot/share/opto/lcm.cpp line 272: > >> 270: const TypePtr* tptr; >> 271: if ((UseCompressedOops || UseCompressedClassPointers) && >> 272: (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) { > > Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled: > > (!UseCompressedOops, UseCompressedClassPointers, CompressedKlassPointers::shift() != 0) > ( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0) Hi @robcasloz The `CompressedKlassPointers` utility class is not usable anymore with `-UseCompressedClassPointers`. One change is that if `UseCompressedClassPointers` is off, `CompressedKlassPointers` stays uninitialized. And that makes more sense then to rely on the static initialization values of `CompressedOops::_shift`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757126946 From bpb at openjdk.org Thu Sep 12 15:43:12 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:43:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeli?ski wrote: > Thanks for making the changes. LGTM, assuming that tests still pass. The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221: > >> 219: static futimesat_func* my_futimesat_func = NULL; >> 220: static futimens_func* my_futimens_func = NULL; >> 221: #ifndef _ALLBSD_SOURCE > > This change looks unrelated. Was it intentional? Yes. The variable on the next line `my_lutimes_func` caused an unused variable error in the macOS build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346633671 PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757123250 From bpb at openjdk.org Thu Sep 12 15:43:13 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:43:13 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote: >> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit. > > Moved to `NTLMAuthentication` static initializer. 853d349 @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757130549 From alanb at openjdk.org Thu Sep 12 15:46:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Sep 2024 15:46:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:38:18 GMT, Brian Burkhalter wrote: > The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. Can you hold off integrating, I plan to go over the changes soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346644977 From stuefe at openjdk.org Thu Sep 12 15:46:17 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Sep 2024 15:46:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: Message-ID: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> On Wed, 11 Sep 2024 14:47:07 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert accidental change of UCOH default > > src/hotspot/share/opto/machnode.cpp line 390: > >> 388: t = t->make_ptr(); >> 389: } >> 390: if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) { > > Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`. I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757135035 From bpb at openjdk.org Thu Sep 12 15:51:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 12 Sep 2024 15:51:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote: > Can you hold off integrating, I plan to go over the changes soon. I don't plan to integrate until you have reviewed it. I set the minimum reviewer count to 3 to avoid doing so accidentally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346655197 From stuefe at openjdk.org Thu Sep 12 16:08:15 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Sep 2024 16:08:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 15:58:29 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147: > >> 145: #endif >> 146: >> 147: return true; > > This should only be in the compressedKlass.cpp file. Okay. I will remove the whole `CompressedKlassPointers::pd_initialize` logic. We only need it for one architecture (aarch) and one case (+UseCCP -UseCOH), so maybe its not worth fanning out across all platforms, including Zero. Instead, I will add a short `ifdef` section to `CompressedKlassPointers::initialize`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757169570 From coleenp at openjdk.org Thu Sep 12 17:37:15 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 12 Sep 2024 17:37:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 16:04:45 GMT, Thomas Stuefe wrote: >> src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 147: >> >>> 145: #endif >>> 146: >>> 147: return true; >> >> This should only be in the compressedKlass.cpp file. > > Okay. I will remove the whole `CompressedKlassPointers::pd_initialize` logic. We only need it for one architecture (aarch) and one case (+UseCCP -UseCOH), so maybe its not worth fanning out across all platforms, including Zero. Instead, I will add a short `ifdef` section to `CompressedKlassPointers::initialize`. Yes, looking at this further, it does seem like a small amount of conditional compilation that sets all the same values that are set in the architecture independent version. It seems best to move it there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1757300544 From erikj at openjdk.org Thu Sep 12 22:38:37 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 12 Sep 2024 22:38:37 GMT Subject: RFR: 8340075: Autoconf bundle cannot run on read-only filesystem Message-ID: The autoconf launcher script in the autoconf bundle created by `make/devkit/createAutoconf.sh` currently writes a config file into the bundle installation dir every time it runs. This prevents it from functioning when installed on a read-only filesystem. We can work around the need for writing to this config file by instead adding a parameter to the command line sent to the actual autoconf executable. This is what the script adds to the config file (with the $this_script_dir variable expanded): begin-language: "M4sugar" args: --prepend-include $this_script_dir/usr/share/autoconf end-language: "M4sugar" Looking at the original config file, it has several lines similar to this where the --prepend-include arg points to $PREFIX/usr/share/autoconf (where $PREFIX was specified at autoconf build time). Removing this addition from the config file causes autoconf to fail as it can't find m4sugar.m4 (which is located in $this_script_dir/usr/share/autoconf). My proposed workaround, is to just add `--prepend-include $this_script_dir/usr/share/autoconf` as a command line option to the real autoconf script, which we call from the wrapper script. This would have the benefit of also fixing the other instances of this that are present in the config file, but that we aren't using in our configure script. In addition to this, I made the script conform better to the current standard for these bundle creation scripts. The output should end up in a sub directory of `build`. No temp dirs should be used instead of the build dir. I also added some automation for setting the target platform tuple based on `uname` for the most common platforms, and added the ability to override for any others, without having to edit the file. ------------- Commit messages: - JDK-8340075 Changes: https://git.openjdk.org/jdk/pull/20978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340075 Stats: 55 lines in 1 file changed: 21 ins; 9 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/20978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20978/head:pull/20978 PR: https://git.openjdk.org/jdk/pull/20978 From rcastanedalo at openjdk.org Fri Sep 13 06:46:15 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 13 Sep 2024 06:46:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> References: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> Message-ID: On Thu, 12 Sep 2024 15:42:59 GMT, Thomas Stuefe wrote: >> src/hotspot/share/opto/machnode.cpp line 390: >> >>> 388: t = t->make_ptr(); >>> 389: } >>> 390: if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) { >> >> Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`. > > I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP. I see, thanks. In that case, I would suggest removing the explicit `UseCompressedClassPointers` test, since it should be implied by `t->isa_narrowklass()`. `check_init()` within `CompressedKlassPointers::shift()` would already fail for the unexpected case where `t->isa_narrowklass() && !UseCompressedClassPointers`, no? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758270661 From rcastanedalo at openjdk.org Fri Sep 13 07:49:15 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 13 Sep 2024 07:49:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Thu, 12 Sep 2024 15:38:18 GMT, Thomas Stuefe wrote: >> src/hotspot/share/opto/lcm.cpp line 272: >> >>> 270: const TypePtr* tptr; >>> 271: if ((UseCompressedOops || UseCompressedClassPointers) && >>> 272: (CompressedOops::shift() == 0 || CompressedKlassPointers::shift() == 0)) { >> >> Could you explain this change? It seems like it may affect C2's implicit null check analysis even for `-XX:-UseCompactObjectHeaders`. In particular, for the following configurations, the changed condition evaluates to true before the change and false after it, regardless of whether `UseCompactObjectHeaders` is enabled: >> >> (!UseCompressedOops, UseCompressedClassPointers, CompressedKlassPointers::shift() != 0) >> ( UseCompressedOops, !UseCompressedClassPointers, CompressedOops::shift() != 0) > > Hi @robcasloz > > The `CompressedKlassPointers` utility class is not usable anymore with `-UseCompressedClassPointers`. One change is that if `UseCompressedClassPointers` is off, `CompressedKlassPointers` stays uninitialized. And that makes more sense then to rely on the static initialization values of `CompressedOops::_shift`. Thanks for the explanation. I wonder if the test is necessary at all, or one could simply use `base->get_ptr_type()` unconditionally, which defaults to `base->bottom_type()->isa_ptr()` anyway for non-compressed pointers. But this simplification would be in any case out of the scope of this changeset. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758356268 From rcastanedalo at openjdk.org Fri Sep 13 07:57:15 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 13 Sep 2024 07:57:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Thu, 12 Sep 2024 11:46:35 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert accidental change of UCOH default > > src/hotspot/share/cds/filemap.cpp line 2457: > >> 2455: compressed_oops(), compressed_class_pointers()); >> 2456: if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) { >> 2457: log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is " > > The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary). This comment has been marked as "resolved" without any apparent action being taken, is that intentional? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758369787 From rkennke at openjdk.org Fri Sep 13 08:21:54 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Sep 2024 08:21:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: Message-ID: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Hide log timestamps in test to prevent false failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/9e008ac1..69f1ef1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=12-13 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Fri Sep 13 08:21:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Sep 2024 08:21:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: <99QfaesSJzBLGXsBKOdiSwjAdt18pwNMh62Pyhr-6bk=.b27f001b-e3e3-4826-9542-698eef2a9ee3@github.com> On Fri, 13 Sep 2024 07:54:30 GMT, Roberto Casta?eda Lozano wrote: >> src/hotspot/share/cds/filemap.cpp line 2457: >> >>> 2455: compressed_oops(), compressed_class_pointers()); >>> 2456: if (compressed_oops() != UseCompressedOops || compressed_class_pointers() != UseCompressedClassPointers) { >>> 2457: log_info(cds)("Unable to use shared archive.\nThe saved state of UseCompressedOops and UseCompressedClassPointers is " >> >> The promotion of this CDS log line from `info` to `warning` triggers false failures in the `test/hotspot/jtreg/compiler/intrinsics/bmi` tests when running them with `-XX:-UseCompressedClassPointers`. These tests expect the standard output of different JVM runs to be identical, but the timestamps in the log messages tend to differ. I suggest adjusting the test configuration so that log timestamps are simply omitted, as in [this patch](https://github.com/robcasloz/jdk/commit/48f6e90ef6e0a71b55df536ed04a8b72130b5ea9) (feel free to merge it as-is or with any further changes you may find necessary). > > This comment has been marked as "resolved" without any apparent action being taken, is that intentional? I have merged your patch locally but forgot to push it. Sorry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758407575 From stuefe at openjdk.org Fri Sep 13 09:30:24 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 13 Sep 2024 09:30:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:19:32 GMT, Coleen Phillimore wrote: >> This is tricky. We are already deep in initialization and have done a couple of decisions based on +UseCompressedClassPointers (e.g. CDS setup). I *think* we could still go with -UseCCP, but I wonder whether this is wise. >> >> Note that this error is not new. In the old code, we simply asserted. That left us with UB in release builds, which remains unresolved. I simply made the error explicit in release too. > > Ok, in this case, that's fine if we already asserted. A fatal error is better. Actually, a lot of the old code had dusty side corners that were UB. Making narrowKlass smaller than 32bit exposed a lot of them, and a lot of the changes in and around CompressedKlassPointers are about cleanly making explicit what before had been implicit or just broken (e.g. a clear distinction between encoding range and Klass range, and a clear handling of narrowKlass bit width as a runtime value). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758522844 From stuefe at openjdk.org Fri Sep 13 09:38:15 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 13 Sep 2024 09:38:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:13:58 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 243: >> >>> 241: } else { >>> 242: >>> 243: // In legacy mode, we try, in order of preference: >> >> Can you not use the word 'legacy' here? Maybe in "non-compact object header mode"... > > okay. I removed all traces of "legacy" and "tiny", reverting to "standard" or "non-coh" vs "coh". I would prefer to use the shorthand "coh" in some places since "compact object header mode" is a mouthful and gives me RSI :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758533732 From stefank at openjdk.org Fri Sep 13 09:44:19 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 13 Sep 2024 09:44:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> References: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> Message-ID: On Fri, 13 Sep 2024 08:21:54 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Hide log timestamps in test to prevent false failures I went over the oops/ directory and added a few cleanup requests and comments. src/hotspot/share/oops/instanceOop.hpp line 43: > 41: } else { > 42: return sizeof(instanceOopDesc); > 43: } This entire function can be removed. It returns the same value as oopDesc::base_offset_in_bytes(), but in a slightly different way. src/hotspot/share/oops/markWord.hpp line 171: > 169: return mask_bits(value(), lock_mask_in_place | self_fwd_mask_in_place) >= static_cast(marked_value); > 170: } > 171: Suggestion to retain code layout. Suggestion: src/hotspot/share/oops/markWord.inline.hpp line 29: > 27: > 28: #include "oops/markWord.hpp" > 29: #include "oops/compressedOops.inline.hpp" Suggestion: #include "oops/compressedOops.inline.hpp" #include "oops/markWord.hpp" src/hotspot/share/oops/objArrayKlass.cpp line 146: > 144: > 145: size_t ObjArrayKlass::oop_size(oop obj) const { > 146: // In this assert, we cannot safely access the Klass* with compact headers. I would like a comment stating that this assert is turned of because size_give_klass calls oop_size on an object that might be concurrently forwarded. src/hotspot/share/oops/oop.cpp line 158: > 156: // Only has a klass gap when compressed class pointers are used and not > 157: // using compact headers. > 158: return UseCompressedClassPointers && !UseCompactObjectHeaders; This comment can just be removed. src/hotspot/share/oops/oop.hpp line 340: > 338: // field offset. Use an offset halfway into the markWord, as the markWord is never > 339: // partially loaded from C2. > 340: return 4; I asked around to see what people felt about dropping references to mark_offset_in_bytes(), which we know is 0. There was a request to strive to use mark_offset_in_bytes() for clarity. Suggestion: return mark_offset_in_bytes() + 4; src/hotspot/share/oops/oop.hpp line 349: > 347: static int klass_gap_offset_in_bytes() { > 348: assert(has_klass_gap(), "only applicable to compressed klass pointers"); > 349: assert(!UseCompactObjectHeaders, "don't use klass_gap_offset_in_bytes() with compact headers"); This assert is implied by `has_klass_gap()`. I don't see the need to repeat it here. src/hotspot/share/oops/oop.hpp line 363: > 361: return sizeof(markWord) + sizeof(Klass*); > 362: } > 363: } Not a strong request for this PR, but there are many places that calculates almost the same thing, and it might be good to limit the number of places we do similar calculations. I'm wondering if it wouldn't be better for readability to structure the code as follows: static int header_size_in_bytes() { if (UseCompactObjectHeaders) { return sizeof(markWord); } else if (UseCompressedClassPointers) { return sizeof(markWord) + sizeof(narrowKlass); } else { return sizeof(markWord) + sizeof(Klass*); } } // Size of object header, aligned to platform wordSize static int header_size() { return align_up(header_size_in_bytes(), HeapWordSize) / HeapWordSize; } ... static int base_offset_in_bytes() { return header_size_in_bytes(); } src/hotspot/share/oops/oop.inline.hpp line 161: > 159: > 160: void oopDesc::set_klass_gap(HeapWord* mem, int v) { > 161: assert(!UseCompactObjectHeaders, "don't set Klass* gap with compact headers"); We might want to consider just simplifying the function to: void oopDesc::set_klass_gap(HeapWord* mem, int v) { assert(has_klass_gap(), "precondition"); *(int*)(((char*)mem) + klass_gap_offset_in_bytes()) = v; } src/hotspot/share/oops/oop.inline.hpp line 295: > 293: // Used by scavengers > 294: void oopDesc::forward_to(oop p) { > 295: assert(cast_from_oop(p) != this, Do we really need the cast here? ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2302542279 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758503206 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758482703 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758505713 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758479437 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758478106 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758472909 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758474349 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758528515 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758538380 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758540055 From stefank at openjdk.org Fri Sep 13 09:44:20 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 13 Sep 2024 09:44:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Mon, 9 Sep 2024 12:17:17 GMT, Thomas Schatzl wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Try to avoid lea in loadNklass (aarch64) >> - Fix release build error > > src/hotspot/share/oops/oop.cpp line 230: > >> 228: // disjunct below to fail if the two comparands are computed across such >> 229: // a concurrent change. >> 230: return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC); > > Is this still true after the recent changes like JDK-8311163? It might be worth waiting for. That bug doesn't fix all cases where the the length field is modified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758477168 From tschatzl at openjdk.org Fri Sep 13 11:15:15 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Sep 2024 11:15:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Fri, 13 Sep 2024 09:00:32 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/oop.cpp line 230: >> >>> 228: // disjunct below to fail if the two comparands are computed across such >>> 229: // a concurrent change. >>> 230: return Universe::heap()->is_stw_gc_active() && klass->is_objArray_klass() && is_forwarded() && (UseParallelGC || UseG1GC); >> >> Is this still true after the recent changes like JDK-8311163? It might be worth waiting for. > > That bug doesn't fix all cases where the the length field is modified. Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163. The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here. If I am not missing some case, this whole method is unnecessary now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758672296 From stuefe at openjdk.org Fri Sep 13 12:51:17 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 13 Sep 2024 12:51:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Tue, 10 Sep 2024 12:35:42 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 116: >> >>> 114: _range = end - _base; >>> 115: >>> 116: DEBUG_ONLY(assert_is_valid_encoding(addr, len, _base, _shift);) >> >> Can you refactor so the aarch64 path runs this same code without duplication? > > In tinycp mode, aarch64 runs this code though? The aarch64 variant of pd_initialize just returns then. In non-COH mode (preexisting, not touched by this patch) Aarch64 needs its own handling. I refactored: Now we should have no duplication (once my patch hits Romans PR branch) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758800913 From stefank at openjdk.org Fri Sep 13 12:51:18 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 13 Sep 2024 12:51:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Fri, 13 Sep 2024 11:10:58 GMT, Thomas Schatzl wrote: >> That bug doesn't fix all cases where the the length field is modified. > > Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163. > > The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here. > > If I am not missing some case, this whole method is unnecessary now. If you've already fixed this for GC then I agree that we could remove this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758805418 From stefank at openjdk.org Fri Sep 13 12:51:18 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 13 Sep 2024 12:51:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Fri, 13 Sep 2024 12:47:09 GMT, Stefan Karlsson wrote: >> Which ones are remaining? JDK-8337709 implemented the same change for G1 GC before JDK-8311163. >> >> The full collectors/g1 marking do not modify the length fields but have multiple separate queues which is a different issue. It will also be handled by the new `PartialArrayTaskStepper`, but should be of no concern here. >> >> If I am not missing some case, this whole method is unnecessary now. > > If you've already fixed this for GC then I agree that we could remove this. This seems like something that should be done as a separate patch that gets pushed before this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758808115 From rkennke at openjdk.org Fri Sep 13 12:56:17 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Sep 2024 12:56:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> Message-ID: On Fri, 13 Sep 2024 09:39:23 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Hide log timestamps in test to prevent false failures > > src/hotspot/share/oops/oop.inline.hpp line 295: > >> 293: // Used by scavengers >> 294: void oopDesc::forward_to(oop p) { >> 295: assert(cast_from_oop(p) != this, > > Do we really need the cast here? Yes, otherwise compiler complains about ambiguous != operator. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758815451 From rkennke at openjdk.org Fri Sep 13 13:03:16 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Sep 2024 13:03:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> Message-ID: On Fri, 13 Sep 2024 09:31:39 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Hide log timestamps in test to prevent false failures > > src/hotspot/share/oops/oop.hpp line 363: > >> 361: return sizeof(markWord) + sizeof(Klass*); >> 362: } >> 363: } > > Not a strong request for this PR, but there are many places that calculates almost the same thing, and it might be good to limit the number of places we do similar calculations. > > I'm wondering if it wouldn't be better for readability to structure the code as follows: > > static int header_size_in_bytes() { > if (UseCompactObjectHeaders) { > return sizeof(markWord); > } else if (UseCompressedClassPointers) { > return sizeof(markWord) + sizeof(narrowKlass); > } else { > return sizeof(markWord) + sizeof(Klass*); > } > } > > // Size of object header, aligned to platform wordSize > static int header_size() { > return align_up(header_size_in_bytes(), HeapWordSize) / HeapWordSize; > } > ... > static int base_offset_in_bytes() { > return header_size_in_bytes(); > } Ok. I filed: https://bugs.openjdk.org/browse/JDK-8340118 for now, let's see if I can sort this out before integrating this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758825458 From rkennke at openjdk.org Fri Sep 13 13:11:45 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 13 Sep 2024 13:11:45 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Various touch-ups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/69f1ef1d..990926f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=13-14 Stats: 25 lines in 8 files changed: 3 ins; 17 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stefank at openjdk.org Fri Sep 13 13:18:16 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 13 Sep 2024 13:18:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v14] In-Reply-To: References: <3-nOaxvBWIcOLzCOlrWPzJtsYRknVz5JIwx21X8xkIg=.6ce32f15-a4d6-44d5-9b9e-c3015de45e66@github.com> Message-ID: On Fri, 13 Sep 2024 12:53:29 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/oop.inline.hpp line 295: >> >>> 293: // Used by scavengers >>> 294: void oopDesc::forward_to(oop p) { >>> 295: assert(cast_from_oop(p) != this, >> >> Do we really need the cast here? > > Yes, otherwise compiler complains about ambiguous != operator. OK, we shouldn't need to. It seems like I can silence the compiler by tweaking oopsHierarchy.hpp. I'll deal with that as a follow-up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758853099 From tschatzl at openjdk.org Fri Sep 13 13:51:16 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 13 Sep 2024 13:51:16 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v8] In-Reply-To: References: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com> Message-ID: On Fri, 13 Sep 2024 12:48:53 GMT, Stefan Karlsson wrote: >> If you've already fixed this for GC then I agree that we could remove this. > > This seems like something that should be done as a separate patch that gets pushed before this PR. Will remove in JDK-8340119. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1758906485 From dfuchs at openjdk.org Fri Sep 13 16:11:15 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter wrote: >> Moved to `NTLMAuthentication` static initializer. 853d349 > > @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759124071 From dfuchs at openjdk.org Fri Sep 13 16:11:15 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs wrote: >> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load? > > hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. I wonder - do you see any failure if you don't load libnet from there? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759125047 From bpb at openjdk.org Fri Sep 13 16:11:15 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:11:15 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote: >> hmm... I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication. > > I wonder - do you see any failure if you don't load libnet from there? Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759128167 From bpb at openjdk.org Fri Sep 13 16:15:16 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:15:16 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote: >> I wonder - do you see any failure if you don't load libnet from there? > > Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. > [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759132986 From dfuchs at openjdk.org Fri Sep 13 16:34:08 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:34:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter wrote: >> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`. > >> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. > > In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759158214 From bpb at openjdk.org Fri Sep 13 16:38:09 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 16:38:09 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote: >>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication. >> >> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`. > > Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. I would have to check. The failure I observed occurred in both of these tests test/jdk/sun/net/www/protocol/http/NoNTLM.java test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java and nowhere else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759166801 From dfuchs at openjdk.org Fri Sep 13 16:48:12 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 13 Sep 2024 16:48:12 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> Message-ID: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter wrote: >> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM. > > I would have to check. The failure I observed occurred in both of these tests > > test/jdk/sun/net/www/protocol/http/NoNTLM.java > test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java > > and nowhere else. I see. The test does: Class ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader()); so that explains it. In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly. What you have is good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759183851 From bpb at openjdk.org Fri Sep 13 17:06:08 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 17:06:08 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v5] In-Reply-To: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> References: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com> <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com> <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com> <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com> Message-ID: <0IMOcZubegYzX-gY4eVUoKl6dSj4FUUkLVO6zYwhTxU=.e0d23617-85fb-4075-be9a-b245205497df@github.com> On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote: >> I would have to check. The failure I observed occurred in both of these tests >> >> test/jdk/sun/net/www/protocol/http/NoNTLM.java >> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java >> >> and nowhere else. > > I see. The test does: > > Class ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader()); > > so that explains it. > > In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly. > > What you have is good to me. Good! Thanks for the assistance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759204325 From mikael at openjdk.org Fri Sep 13 18:02:04 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 13 Sep 2024 18:02:04 GMT Subject: RFR: 8340075: Autoconf bundle cannot run on read-only filesystem In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 22:33:43 GMT, Erik Joelsson wrote: > The autoconf launcher script in the autoconf bundle created by `make/devkit/createAutoconf.sh` currently writes a config file into the bundle installation dir every time it runs. This prevents it from functioning when installed on a read-only filesystem. We can work around the need for writing to this config file by instead adding a parameter to the command line sent to the actual autoconf executable. > > This is what the script adds to the config file (with the $this_script_dir variable expanded): > > begin-language: "M4sugar" > args: --prepend-include $this_script_dir/usr/share/autoconf > end-language: "M4sugar" > > Looking at the original config file, it has several lines similar to this where the --prepend-include arg points to $PREFIX/usr/share/autoconf (where $PREFIX was specified at autoconf build time). Removing this addition from the config file causes autoconf to fail as it can't find m4sugar.m4 (which is located in $this_script_dir/usr/share/autoconf). > > My proposed workaround, is to just add `--prepend-include $this_script_dir/usr/share/autoconf` as a command line option to the real autoconf script, which we call from the wrapper script. This would have the benefit of also fixing the other instances of this that are present in the config file, but that we aren't using in our configure script. > > In addition to this, I made the script conform better to the current standard for these bundle creation scripts. The output should end up in a sub directory of `build`. No temp dirs should be used instead of the build dir. I also added some automation for setting the target platform tuple based on `uname` for the most common platforms, and added the ability to override for any others, without having to edit the file. Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20978#pullrequestreview-2303741685 From erikj at openjdk.org Fri Sep 13 18:34:08 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Sep 2024 18:34:08 GMT Subject: Integrated: 8340075: Autoconf bundle cannot run on read-only filesystem In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 22:33:43 GMT, Erik Joelsson wrote: > The autoconf launcher script in the autoconf bundle created by `make/devkit/createAutoconf.sh` currently writes a config file into the bundle installation dir every time it runs. This prevents it from functioning when installed on a read-only filesystem. We can work around the need for writing to this config file by instead adding a parameter to the command line sent to the actual autoconf executable. > > This is what the script adds to the config file (with the $this_script_dir variable expanded): > > begin-language: "M4sugar" > args: --prepend-include $this_script_dir/usr/share/autoconf > end-language: "M4sugar" > > Looking at the original config file, it has several lines similar to this where the --prepend-include arg points to $PREFIX/usr/share/autoconf (where $PREFIX was specified at autoconf build time). Removing this addition from the config file causes autoconf to fail as it can't find m4sugar.m4 (which is located in $this_script_dir/usr/share/autoconf). > > My proposed workaround, is to just add `--prepend-include $this_script_dir/usr/share/autoconf` as a command line option to the real autoconf script, which we call from the wrapper script. This would have the benefit of also fixing the other instances of this that are present in the config file, but that we aren't using in our configure script. > > In addition to this, I made the script conform better to the current standard for these bundle creation scripts. The output should end up in a sub directory of `build`. No temp dirs should be used instead of the build dir. I also added some automation for setting the target platform tuple based on `uname` for the most common platforms, and added the ability to override for any others, without having to edit the file. This pull request has now been integrated. Changeset: 3aa8338f Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/3aa8338f4e7d88967e77dfb0bace1c4b5add72f1 Stats: 55 lines in 1 file changed: 21 ins; 9 del; 25 mod 8340075: Autoconf bundle cannot run on read-only filesystem Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/20978 From ihse at openjdk.org Fri Sep 13 19:33:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 13 Sep 2024 19:33:18 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Clean up to address reviewer comments make/modules/java.base/lib/CoreLibraries.gmk line 68: > 66: JDK_LIBS := libjvm, \ > 67: LIBS_linux := $(LIBDL) -lpthread, \ > 68: LIBS_aix := $(LIBDL) $(LIBM),\ Suggestion: LIBS_aix := $(LIBDL) $(LIBM), \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759390367 From bpb at openjdk.org Fri Sep 13 20:41:27 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 20:41:27 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: References: Message-ID: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8337143: Minor makefile tweak ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/853d3491..b54b1683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Fri Sep 13 20:41:28 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 13 Sep 2024 20:41:28 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com> Message-ID: <8y7e4b_Phw8ehQRM0kbQom0w3WD91u7B5ujYIiGl6P4=.eab2e1ad-3a81-4c7e-8e14-cc6b51a377d0@github.com> On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8337143: Clean up to address reviewer comments > > make/modules/java.base/lib/CoreLibraries.gmk line 68: > >> 66: JDK_LIBS := libjvm, \ >> 67: LIBS_linux := $(LIBDL) -lpthread, \ >> 68: LIBS_aix := $(LIBDL) $(LIBM),\ > > Suggestion: > > LIBS_aix := $(LIBDL) $(LIBM), \ So changed in b54b168. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759474420 From stuefe at openjdk.org Sun Sep 15 06:17:14 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 15 Sep 2024 06:17:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v13] In-Reply-To: References: <4iHDH-GpSa-uPqe0IwwP6notHRyrOTiecqCSX9kYCe0=.d7969fd0-3066-42fa-82d4-842c10baee1c@github.com> Message-ID: On Wed, 11 Sep 2024 21:15:21 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert accidental change of UCOH default > > I was starting to understand the concerns with having prototype_header in Klass. It seems like it would simplify encoding the klass for object allocation. My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this. You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor. > > diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp > index fd198f54fc9..7aa4bd24948 100644 > --- a/src/hotspot/share/oops/instanceKlass.cpp > +++ b/src/hotspot/share/oops/instanceKlass.cpp > @@ -511,7 +511,7 @@ InstanceKlass::InstanceKlass() { > } > > InstanceKlass::InstanceKlass(const ClassFileParser& parser, KlassKind kind, ReferenceType reference_type) : > - Klass(kind), > + Klass(kind, (!parser.is_interface() && !parser.is_abstract())), > _nest_members(nullptr), > _nest_host(nullptr), > _permitted_subclasses(nullptr), @coleenp > I was starting to understand the concerns with having prototype_header in Klass. It seems like it would simplify encoding the klass for object allocation. My recent change https://bugs.openjdk.org/browse/JDK-8338526 breaks this. You need to pass a parameter to Klass() to tell whether to encode the klass pointer or not, and pass this to Klass() constructor. > I solved this differently (Roman will merge this into his PR). static markWord make_prototype(const Klass* kls) { markWord prototype = markWord::prototype(); #ifdef _LP64 if (UseCompactObjectHeaders) { // With compact object headers, the narrow Klass ID is part of the mark word. // We therfore seed the mark word with the narrow Klass ID. // Note that only those Klass that can be instantiated have a narrow Klass ID. // For those who don't, we leave the klass bits empty and assert if someone // tries to use those. const narrowKlass nk = CompressedKlassPointers::is_encodable(kls) ? CompressedKlassPointers::encode(const_cast(kls)) : 0; prototype = prototype.set_narrow_klass(nk); } #endif return prototype; } inline bool CompressedKlassPointers::is_encodable(const void* address) { check_init(_base); // An address can only be encoded if: // // 1) the address lies within the klass range. // 2) It is suitably aligned to 2^encoding_shift. This only really matters for // +UseCompactObjectHeaders, since the encoding shift can be large (max 10 bits -> 1KB). return is_aligned(address, klass_alignment_in_bytes()) && address >= _klass_range_start && address < _klass_range_end; } So, we put an nKlass into the prototype if we can. We can, if the Klass address is encodable. It is encodable if it lives in the encoded Klass range and is correctly aligned. No need to pass this information via another channel: its right there, in the Klass address. This works even before Klass is initialized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2351399143 From stuefe at openjdk.org Sun Sep 15 06:17:15 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 15 Sep 2024 06:17:15 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 11:25:41 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/metaspace/metablock.hpp line 51: > >> 49: size_t word_size() const { return _word_size; } >> 50: bool is_empty() const { return _base == nullptr; } >> 51: bool is_nonempty() const { return _base != nullptr; } > > Can `_base == nullptr` but `_word_size != 0`? No ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1759973362 From rcastanedalo at openjdk.org Mon Sep 16 06:56:18 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 16 Sep 2024 06:56:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> On Fri, 13 Sep 2024 13:11:45 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Various touch-ups src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576: > 2574: } else { > 2575: lea(dst, Address(obj, index, Address::lsl(scale))); > 2576: ldr(dst, Address(dst, offset)); Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1760617744 From luhenry at openjdk.org Mon Sep 16 07:29:07 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 16 Sep 2024 07:29:07 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v5] In-Reply-To: References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: On Fri, 30 Aug 2024 16:57:18 GMT, Magnus Ihse Bursie wrote: >> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. >> >> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Use "whitespace" as an uncountable noun > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > - I suck at English verb forms > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2305912067 From rcastanedalo at openjdk.org Mon Sep 16 08:07:18 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 16 Sep 2024 08:07:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 13:11:45 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Various touch-ups > * Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version. An alternative that seems promising is to hide the object header klass pointer extraction and make it part of the `LoadNKlass` node semantics, as illustrated in this example: ![alternative-modeling](https://github.com/user-attachments/assets/06243966-3065-4969-a2dd-d05133b36366) `LoadNKlass` nodes can then be expanded into more primitive operations (load and shift for compact headers, load with `klass_offset_in_bytes()` for original headers) within C2's back-end or even during code emission as sketched [here](https://github.com/robcasloz/jdk/commit/6cb4219f101e3be982264071c2cb1d0af1c6d754). @rkennke is this similar to what you tried out ("Expanding it as a macro")? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2352253326 From ihse at openjdk.org Mon Sep 16 10:22:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 10:22:11 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> References: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> Message-ID: On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Minor makefile tweak Make changes look fine now. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2306245227 From ihse at openjdk.org Mon Sep 16 10:30:46 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 10:30:46 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v6] In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. > > This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update legal/sleef.md ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20781/files - new: https://git.openjdk.org/jdk/pull/20781/files/e5fe681e..83dddf1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=04-05 Stats: 407 lines in 1 file changed: 404 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781 PR: https://git.openjdk.org/jdk/pull/20781 From magnus.ihse.bursie at oracle.com Mon Sep 16 10:32:22 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 12:32:22 +0200 Subject: Is it possible to have the build in github's PR checks section to keep compiling files after an error? In-Reply-To: References: Message-ID: <79ae4dec-26f8-4d7f-b9b7-66a943da6a5a@oracle.com> Yeah, that is probably a good idea. We could use `make -k`. The additional cost of continuing to build even in a failed build is pretty small compared to the overhead of having to resubmit the entire GHA several times. I opened https://bugs.openjdk.org/browse/JDK-8340185. /Magnus On 2024-09-06 21:55, Gerard Ziemski wrote: > hi, > > Is it possible to have the build in github's PR checks section keep compiling files after an error is encountered? > > This would help limit number of times a fix and commit is required, for a large changes involving refactoring/renaming changes that touch lots of files. This in turn would limit the number of times the build must be spun up to find/fix all errors. > > As it is, the current build check task bails out at 1st error, and only provides error reports for a single file at a time. > > > cheers > From jpai at openjdk.org Mon Sep 16 11:37:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 16 Sep 2024 11:37:31 GMT Subject: RFR: 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file Message-ID: Can I please get a review of this trivial change in the `LauncherCommon.gmk` file which replaces the use of the outdated `-ms` option with `-Xms`? This is a cleanup prior to the effort of deprecating the outdated `-ms` launcher option for removal. Local build on a macosx M1 passed with this change. CI build against various platforms is currently in progress. ------------- Commit messages: - 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file Changes: https://git.openjdk.org/jdk/pull/21017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21017&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340194 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21017/head:pull/21017 PR: https://git.openjdk.org/jdk/pull/21017 From rkennke at openjdk.org Mon Sep 16 12:38:00 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 16 Sep 2024 12:38:00 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v16] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits: - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java - Fix loop on aarch64 - clarify obscure assert in metasapce setup - Rework compressedklass encoding - remove stray debug output - Fixes post 8338526 - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4 - Various touch-ups - Hide log timestamps in test to prevent false failures - Revert accidental change of UCOH default - ... and 43 more: https://git.openjdk.org/jdk/compare/59778885...49c87547 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=15 Stats: 4605 lines in 190 files changed: 3252 ins; 724 del; 629 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From ihse at openjdk.org Mon Sep 16 12:39:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 12:39:08 GMT Subject: RFR: 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 11:31:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change in the `LauncherCommon.gmk` file which replaces the use of the outdated `-ms` option with `-Xms`? > > This is a cleanup prior to the effort of deprecating the outdated `-ms` launcher option for removal. > > Local build on a macosx M1 passed with this change. CI build against various platforms is currently in progress. Thanks for cleaning up! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21017#pullrequestreview-2306519730 From magnus.ihse.bursie at oracle.com Mon Sep 16 13:24:15 2024 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Sep 2024 15:24:15 +0200 Subject: Tool suggestion: binsider Message-ID: I recently learned about "binsider", a new text-based UI tool for analyzing ELF files. It seems pretty nice. It does not really give you anything that was not already available through other means, but it does so in a way that provides better navigation and overview. I have just tested it for a short time, but I like what I have seen. https://binsider.dev/ /Magnus From rkennke at openjdk.org Mon Sep 16 13:28:00 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 16 Sep 2024 13:28:00 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v17] In-Reply-To: References: Message-ID: <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java - Fix loop on aarch64 - clarify obscure assert in metasapce setup - Rework compressedklass encoding - remove stray debug output - Fixes post 8338526 - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4 - Various touch-ups - Hide log timestamps in test to prevent false failures - ... and 44 more: https://git.openjdk.org/jdk/compare/54595188...2125cd81 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=16 Stats: 4598 lines in 190 files changed: 3245 ins; 719 del; 634 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Mon Sep 16 13:31:17 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 16 Sep 2024 13:31:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 13:13:01 GMT, Roman Kennke wrote: >>> @rkennke Can you please explain the changes in these tests: >>> >>> ``` >>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java >>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java >>> test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java >>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java >>> test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java >>> ``` >>> >>> You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` >>> >>> This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. >>> >>> I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? >>> >>> Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. >>> >>> Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). >> >> IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. >> >> I will re-evaluate those tests, and add comments or remove the restrictions. > >> > > @rkennke Can you please explain the changes in these tests: >> > > ``` >> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java >> > > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java >> > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java >> > > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java >> > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java >> > > ``` >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > You added these IR rule restriction: `@IR(applyIf = {"UseCompactObjectHeaders", "false"},` >> > > This means that if `UseCompactObjectHeaders` is enabled, vectorization seems to be impacted - that could be concerning because it has a performance impact. >> > > I have recently changed a few things in SuperWord, so maybe some of them can be removed, because they now vectorize anyway? >> > > Of course some special tests may just rely on `UseCompactObjectHeaders == false` - but I would need some comments in the tests where you added it to justify why we add the restriction. >> > > Please also test this patch with the cross combinations of `UseCompactObjectHeaders` and `AlignVector` enabled and disabled (and add `VerifyAlignVector` as well). >> > >> > >> > IIRC (it has been a while), the problem is that with Lilliput (and also without compact headers, but disabling compressed class-pointers -UseCompressedClassPointers, but nobody ever does that), byte[] and long[] start at different offsets (12 and 16, respectively). That is because with compact headers, we are using the 4 bytes after the arraylength, but long-arrays cannot do that because of alignment constraints. The impact is that these tests don't work as expected, because vectorization triggers differently. I don't remember the details, TBH, but I believe they would now generate pre-loops, or some might even not vectorize at all. Those seemed to be use-cases that did not look very important, but I may be wrong. It would be nice to properly fix those tests, or make corresponding tests for compact headers, instead, or improve vectorization to better deal with the offset mismatch, if necessary/possible. >> > I will re-evaluate those tests, and add comments or remove the restrictions. >> >> If it has indeed been a while, then it might well be that some of them work now, since I did make some improvements to auto-vectorization ... > `LoadNKlass` nodes can then be expanded into more primitive operations (load and shift for compact headers, load with `klass_offset_in_bytes()` for original headers) within C2's back-end or even during code emission as sketched [here](https://github.com/robcasloz/jdk/commit/6cb4219f101e3be982264071c2cb1d0af1c6d754). @rkennke is this similar to what you tried out ("Expanding it as a macro")? No, this is not what I tried. I tried to completely expand LoadNKlass, and replace it with the lower nodes that load and shift the mark-word right there, in ideal graph. But your approach is saner: there is so much implicit knowledge about Load(N)Klass, and even klass_offset_in_bytes(), all over the place, it would be very hard to get this right without breaking something. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2352926265 From jwaters at openjdk.org Mon Sep 16 13:40:04 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 16 Sep 2024 13:40:04 GMT Subject: RFR: 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 11:31:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change in the `LauncherCommon.gmk` file which replaces the use of the outdated `-ms` option with `-Xms`? > > This is a cleanup prior to the effort of deprecating the outdated `-ms` launcher option for removal. > > Local build on a macosx M1 passed with this change. CI build against various platforms is currently in progress. Looks simple enough, thanks ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/21017#pullrequestreview-2306695323 From jpai at openjdk.org Mon Sep 16 13:57:05 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 16 Sep 2024 13:57:05 GMT Subject: RFR: 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 11:31:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change in the `LauncherCommon.gmk` file which replaces the use of the outdated `-ms` option with `-Xms`? > > This is a cleanup prior to the effort of deprecating the outdated `-ms` launcher option for removal. > > Local build on a macosx M1 passed with this change. CI build against various platforms is currently in progress. Thank you Magnus and Julian for the reviews. Since this is a trivial change and the local and internal CI builds completed successfully, I'll go ahead with the integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21017#issuecomment-2352995130 From jpai at openjdk.org Mon Sep 16 14:09:11 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 16 Sep 2024 14:09:11 GMT Subject: Integrated: 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file In-Reply-To: References: Message-ID: <0IJK9RTtQO3_RsROwTU4ftd8n0i5s0gYA1IOECfJYvI=.598542da-0403-4043-9e24-9e51b7304440@github.com> On Mon, 16 Sep 2024 11:31:57 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change in the `LauncherCommon.gmk` file which replaces the use of the outdated `-ms` option with `-Xms`? > > This is a cleanup prior to the effort of deprecating the outdated `-ms` launcher option for removal. > > Local build on a macosx M1 passed with this change. CI build against various platforms is currently in progress. This pull request has now been integrated. Changeset: 05b9d479 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/05b9d47905a0dd6dd7a042f940fe120d3a8338d1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8340194: Replace usage of -ms with -Xms in LauncherCommon.gmk make file Reviewed-by: ihse, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/21017 From sgehwolf at openjdk.org Mon Sep 16 16:15:32 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 16 Sep 2024 16:15:32 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v37] In-Reply-To: References: Message-ID: > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b eing modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 143 commits: - Update error message when linking jdk.jlink - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - Merge branch 'master' into jdk-8311302-jmodless-link - JLinkDedupTestBatchSizeOne.java test fix Run only the packaged modules version if we have a linkable JDK runtime with packaged modules available as well in the JDK install. - Enable IncludeLocalesPluginTest - Enable GenerateJLIClassesPluginTest.java test - Enable JLinkReproducibleTest.java for linkable JDK images - ... and 133 more: https://git.openjdk.org/jdk/compare/996790c7...182c4aa5 ------------- Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=36 Stats: 3959 lines in 42 files changed: 3762 ins; 117 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From aboldtch at openjdk.org Mon Sep 16 16:21:20 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 16 Sep 2024 16:21:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v17] In-Reply-To: <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com> References: <_5gI7i33xrOgXMTI_04oX9UDGwhVTtSNWoSiNfM3FOM=.b24979b3-dcde-401f-b2d8-9b201d303f57@github.com> Message-ID: On Mon, 16 Sep 2024 13:28:00 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 54 commits: > > - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 > - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java > - Fix loop on aarch64 > - clarify obscure assert in metasapce setup > - Rework compressedklass encoding > - remove stray debug output > - Fixes post 8338526 > - Merge commit '597788850041e7272a23714c05ba546ee6080856' into JDK-8305895-v4 > - Various touch-ups > - Hide log timestamps in test to prevent false failures > - ... and 44 more: https://git.openjdk.org/jdk/compare/54595188...2125cd81 src/hotspot/cpu/aarch64/aarch64.ad line 6459: > 6457: format %{ "ldrw $dst, $mem\t# compressed class ptr" %} > 6458: ins_encode %{ > 6459: __ load_nklass_compact_c2($dst$$Register, $mem$$base$$Register, $mem$$index$$Register, $mem$$scale, $mem$$disp); I wonder if something along the line of this is required here. Suggestion: Address addr = mem2address($mem->opcode(), $mem$$base$$Register, $mem$$index, $mem$$scale, $mem$$disp); __ load_nklass_compact_c2($dst$$Register, __ adjust_compact_object_header_address_c2(addr, rscratch1)); With `adjust_compact_object_header_address_c2` being: ```C++ Address C2_MacroAssembler::adjust_compact_object_header_address_c2(Address addr, Register tmp) { // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract // obj-start, so that we can load from the object's mark-word instead. Usually the address // comes as obj-start in addr.base() and klass_offset_in_bytes in addr.offset(). if (addr.getMode() != Address::base_plus_offset) { lea(tmp, addr); addr = Address(tmp, -oopDesc::klass_offset_in_bytes()); } else { addr = Address(addr.base(), addr.offset() - oopDesc::klass_offset_in_bytes()); } return legitimize_address(addr, 8, tmp); } Maybe it is the case that we never get the case where `$mem->opcode()` is not `lsl` variant, nor that the offset is to far away for an immediate fixed by `legitimize_address`. But it seems like this would at least make those cases correct, while avoiding the `lea` in the common case. Maybe someone with better experience in aarch64 macroassembler+ad files and C2 can give an opinion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1761455581 From mikael at openjdk.org Mon Sep 16 17:30:21 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 16 Sep 2024 17:30:21 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v6] In-Reply-To: References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: On Mon, 16 Sep 2024 10:30:46 GMT, Magnus Ihse Bursie wrote: >> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. >> >> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update legal/sleef.md make/UpdateSleefSource.gmk line 48: > 46: > 47: ifeq ($(CMAKE), ) > 48: $(error CMake not found. Please install cmake and rerun confugure) typo -> configure make/UpdateSleefSource.gmk line 132: > 130: $(CROSS_COMPILATION_SRC_FILES): $(sleef_cross_build) > 131: > 132: # Finally, copy the generated files (and one needed static files) into our files -> file (or drop "one") src/jdk.incubator.vector/linux/native/libsleef/README.md line 28: > 26: To update the version of libsleef that is used in the JDK, clone > 27: `https://github.com/shibatch/sleef.git`, and copy all files, except the `docs` > 28: and `.github` directories, into And, for completeness, `.git` src/jdk.incubator.vector/linux/native/libsleef/README.md line 49: > 47: > 48: Now, you can repeat this for the next platform. For instance, you can > 49: create a separate profile using `configure --with-conf-name=riscv64` and then profile -> configuration? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1761517507 PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1761522889 PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1761563950 PR Review Comment: https://git.openjdk.org/jdk/pull/20781#discussion_r1761530302 From scolebourne at openjdk.org Mon Sep 16 19:00:17 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Mon, 16 Sep 2024 19:00:17 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato wrote: >> This is a follow on fix to [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone." Same fix, i.e, replacing `startsWith()` with `regionMatches()` was applied. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > tz files aligned with the default TzdbZoneRulesProvider list make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308: > 306: if (off < tokens.length) { > 307: String dayRule = tokens[off++]; > 308: if (dayRule.regionMatches(true, 0, "last", 0, 4)) { This isn't correct, as per the mailing list: > > can "last" contain uppercase letters, or > > does it have to be exactly "last"? > > In that case the name is "lastSunday", and it can be abbreviated > "lastSu" or "Lastsu" or "LASTSUNDA" or whatever. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761697764 From naoto at openjdk.org Mon Sep 16 19:33:09 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 16 Sep 2024 19:33:09 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 18:57:42 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> tz files aligned with the default TzdbZoneRulesProvider list > > make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308: > >> 306: if (off < tokens.length) { >> 307: String dayRule = tokens[off++]; >> 308: if (dayRule.regionMatches(true, 0, "last", 0, 4)) { > > This isn't correct, as per the mailing list: > >> > can "last" contain uppercase letters, or >> > does it have to be exactly "last"? >> >> In that case the name is "lastSunday", and it can be abbreviated >> "lastSu" or "Lastsu" or "LASTSUNDA" or whatever. Why is it not? IIUC, abbreviation should be unambiguous, so "last" part is always case-insensitive 4 character length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761768765 From scolebourne at openjdk.org Mon Sep 16 19:39:09 2024 From: scolebourne at openjdk.org (Stephen Colebourne) Date: Mon, 16 Sep 2024 19:39:09 GMT Subject: RFR: 8339803: Acknowledge case insensitive unambiguous keywords in tzdata files [v2] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 19:30:56 GMT, Naoto Sato wrote: >> make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308: >> >>> 306: if (off < tokens.length) { >>> 307: String dayRule = tokens[off++]; >>> 308: if (dayRule.regionMatches(true, 0, "last", 0, 4)) { >> >> This isn't correct, as per the mailing list: >> >>> > can "last" contain uppercase letters, or >>> > does it have to be exactly "last"? >>> >>> In that case the name is "lastSunday", and it can be abbreviated >>> "lastSu" or "Lastsu" or "LASTSUNDA" or whatever. > > Why is it not? IIUC, abbreviation should be unambiguous, so "last" part is always case-insensitive 4 character length. Sorry, I assumed this regionMatches was the same as the others. "last" is always "last" and never abbreviated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20940#discussion_r1761774912 From djelinski at openjdk.org Tue Sep 17 06:09:07 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 17 Sep 2024 06:09:07 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v8] In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> References: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com> Message-ID: On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8337143: Minor makefile tweak Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2308420140 From rkennke at openjdk.org Tue Sep 17 09:35:02 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Sep 2024 09:35:02 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v18] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - fix CompressedClassPointersEncodingScheme yet again for linux aarch64 - Fixes post-8340184 - Merge upstream up to and including 8340184 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java - Fix loop on aarch64 - clarify obscure assert in metasapce setup - Rework compressedklass encoding - remove stray debug output - Fixes post 8338526 - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=17 Stats: 4518 lines in 190 files changed: 3180 ins; 718 del; 620 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Tue Sep 17 10:02:17 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:02:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 12:25:37 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/classLoaderMetaspace.hpp line 81: > >> 79: metaspace::MetaspaceArena* class_space_arena() const { return _class_space_arena; } >> 80: >> 81: bool have_class_space_arena() const { return _class_space_arena != nullptr; } > > This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers` I'd prefer not to. This logic (when -UCCP class space arena is NULL, with the implicit assumption that both are different entities) has been in there forever, and changing that is out of scope for and unrelated to this PR. I am not sure what will break if I change this but don't want to chase risk test errors at this point (one example, reporting would have to be adapted to recognize that both arenas are the same, and there are plenty of tests that would also need to be fixd). This can be done in a follow-up RFE if necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762917467 From stuefe at openjdk.org Tue Sep 17 10:05:20 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:05:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 13:05:10 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/classLoaderMetaspace.cpp line 165: > >> 163: MetaBlock bl(ptr, word_size); >> 164: // If the block would be reusable for a Klass, add to class arena, otherwise to >> 165: // then non-class arena. > > Nit: spelling, "the" Okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762928041 From stuefe at openjdk.org Tue Sep 17 10:16:24 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:16:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 13:50:59 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/metaspace.cpp line 656: > >> 654: // Adjust size of the compressed class space. >> 655: >> 656: const size_t res_align = reserve_alignment(); > > Can you change the name to `root_chunk_size`? It feels wrong, since this is a deeply hidden implementation detail.\ I will remove this temporary variable, which will also make the diff smaller. > src/hotspot/share/memory/metaspace.hpp line 112: > >> 110: static size_t max_allocation_word_size(); >> 111: >> 112: // Minimum allocation alignment, in bytes. All MetaData shall be aligned correclty > > Nit: Spelling, "correctly" Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762968742 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762972938 From stuefe at openjdk.org Tue Sep 17 10:23:19 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:23:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 11:25:56 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/metaspace/metablock.hpp line 48: > >> 46: >> 47: MetaWord* base() const { return _base; } >> 48: const MetaWord* end() const { return _base + _word_size; } > > `assert(is_nonempty())` Raises the question of why here and not in other accessors? Note that the only patch via which end() is called already asserts for non-empty-ness (MetaspaceArena::contains). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762985723 From jsjolen at openjdk.org Tue Sep 17 10:31:19 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 17 Sep 2024 10:31:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 09:59:49 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/classLoaderMetaspace.hpp line 81: >> >>> 79: metaspace::MetaspaceArena* class_space_arena() const { return _class_space_arena; } >>> 80: >>> 81: bool have_class_space_arena() const { return _class_space_arena != nullptr; } >> >> This is unnecessary. Instead of having this and having to remember to check for nullness each time, just change the `_class_space_arena` to point to the same arena as the `_non_class_space_arena` does when we run with `-XX:-UseCompressedClassPointers` > > I'd prefer not to. > > This logic (when -UCCP class space arena is NULL, with the implicit assumption that both are different entities) has been in there forever, and changing that is out of scope for and unrelated to this PR. I am not sure what will break if I change this but don't want to risk test errors at this point (one example, reporting would have to be adapted to recognize that both arenas are the same, and there are plenty of tests that would also need to be fixd). > > This can be done in a follow-up RFE if necessary. OK, that's fine. >> src/hotspot/share/memory/metaspace.cpp line 656: >> >>> 654: // Adjust size of the compressed class space. >>> 655: >>> 656: const size_t res_align = reserve_alignment(); >> >> Can you change the name to `root_chunk_size`? > > It feels wrong, since this is a deeply hidden implementation detail.\ > > I will remove this temporary variable, which will also make the diff smaller. Sounds OK, I wanted the name change to indicate that "hey, deep impl detail where we use this to mean something else". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762993568 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762994772 From stuefe at openjdk.org Tue Sep 17 10:31:20 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:31:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: <32_SIVHDWyZyYSvbV1jUHc631MTKUP2Thh_M9Q71jrc=.351aed23-599d-4a53-9cc0-0e9c85ecdf03@github.com> On Wed, 11 Sep 2024 11:29:38 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/metaspace/metablock.hpp line 52: > >> 50: bool is_empty() const { return _base == nullptr; } >> 51: bool is_nonempty() const { return _base != nullptr; } >> 52: void reset() { _base = nullptr; _word_size = 0; } > > Is this function really necessary? According to my IDE it's only used in tests and even then the `MetaBlock` isn't used afterwards (so it has no effect). see test_clms.cpp, test_random function, used in two places there. > src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 84: > >> 82: // between threads and needs to be synchronized in CLMS. >> 83: >> 84: const size_t _allocation_alignment_words; > > Nit: Document this? All other members are documented. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762993378 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762995731 From stuefe at openjdk.org Tue Sep 17 10:31:23 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 17 Sep 2024 10:31:23 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v18] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 11:40:24 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - fix CompressedClassPointersEncodingScheme yet again for linux aarch64 >> - Fixes post-8340184 >> - Merge upstream up to and including 8340184 >> - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 >> - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java >> - Fix loop on aarch64 >> - clarify obscure assert in metasapce setup >> - Rework compressedklass encoding >> - remove stray debug output >> - Fixes post 8338526 >> - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed > > src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 44: > >> 42: class FreeBlocks; >> 43: >> 44: struct ArenaStats; > > Nit: Sort? ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1762994972 From jsjolen at openjdk.org Tue Sep 17 10:47:25 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 17 Sep 2024 10:47:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v18] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 09:35:02 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - fix CompressedClassPointersEncodingScheme yet again for linux aarch64 > - Fixes post-8340184 > - Merge upstream up to and including 8340184 > - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 > - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java > - Fix loop on aarch64 > - clarify obscure assert in metasapce setup > - Rework compressedklass encoding > - remove stray debug output > - Fixes post 8338526 > - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed Hi, We've gone through the rest of the Metaspace code and looked at the tests. It looks OK to us. Would like to see some style cleanups in the tests, but that can wait as a follow up. test/hotspot/gtest/metaspace/test_clms.cpp line 193: > 191: > 192: { > 193: // Nonclass arena allocation. The style in this source file isn't really up to scratch, especially *these* lines. Anyway, it's in the tests, so I'm OK with this being fixed in a follow up RFE. ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2309360771 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1763005291 From ihse at openjdk.org Tue Sep 17 12:47:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 17 Sep 2024 12:47:24 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v7] In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. > > This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20781/files - new: https://git.openjdk.org/jdk/pull/20781/files/83dddf1f..b625318d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20781&range=05-06 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20781/head:pull/20781 PR: https://git.openjdk.org/jdk/pull/20781 From rkennke at openjdk.org Tue Sep 17 12:52:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Sep 2024 12:52:03 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - CompressedKlassPointers::is_encodable shall be callable with -UseCCP - Johan review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/28a26aed..612d3045 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=17-18 Stats: 39 lines in 7 files changed: 22 ins; 8 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From erikj at openjdk.org Tue Sep 17 12:53:10 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 17 Sep 2024 12:53:10 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v7] In-Reply-To: References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: On Tue, 17 Sep 2024 12:47:24 GMT, Magnus Ihse Bursie wrote: >> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. >> >> This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20781#pullrequestreview-2309666639 From ihse at openjdk.org Tue Sep 17 13:01:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 17 Sep 2024 13:01:15 GMT Subject: Integrated: 8329816: Add SLEEF version 3.6.1 In-Reply-To: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> References: <0jiUrj5NGvjH0SFZpGfNVI-6IiQSIb_wmlRKdcTv5i8=.cf61b636-e36c-4672-aeeb-227bf509923a@github.com> Message-ID: On Thu, 29 Aug 2024 23:07:16 GMT, Magnus Ihse Bursie wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. > > This is a new attempt at solving [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816); the original attempt is here: https://github.com/openjdk/jdk/pull/19185. This PR is based on the discussions on how to move forward that was held in that original PR. This pull request has now been integrated. Changeset: b39e6a84 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/b39e6a84ef947661b5c878d02213da3a79bc026c Stats: 120709 lines in 175 files changed: 120709 ins; 0 del; 0 mod 8329816: Add SLEEF version 3.6.1 Reviewed-by: erikj, mli, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/20781 From mikael at openjdk.org Tue Sep 17 23:21:14 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Tue, 17 Sep 2024 23:21:14 GMT Subject: Withdrawn: 8329816: Add SLEEF version 3.6.1 In-Reply-To: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com> References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com> Message-ID: On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19185 From rkennke at openjdk.org Wed Sep 18 12:11:31 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Sep 2024 12:11:31 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> References: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> Message-ID: On Mon, 16 Sep 2024 06:53:42 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Various touch-ups > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576: > >> 2574: } else { >> 2575: lea(dst, Address(obj, index, Address::lsl(scale))); >> 2576: ldr(dst, Address(dst, offset)); > > Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well? AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like r27[nklass]+offset, that's why we need to lea the r27[nklass] part first. Yes, this also happens on x86, but x86 supports rX[nklass]+offset addressing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1764937842 From rkennke at openjdk.org Wed Sep 18 12:25:50 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Sep 2024 12:25:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v20] In-Reply-To: References: Message-ID: <1o2b4fxBhqrlRqkNwKqZD1mgRNfTM16_NHZweEbd9SI=.1f68868b-1b98-4f78-9d37-2a805ffc932b@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 - CompressedKlassPointers::is_encodable shall be callable with -UseCCP - Johan review feedback - fix CompressedClassPointersEncodingScheme yet again for linux aarch64 - Fixes post-8340184 - Merge upstream up to and including 8340184 - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java - Fix loop on aarch64 - clarify obscure assert in metasapce setup - ... and 50 more: https://git.openjdk.org/jdk/compare/19b2cee4...bb641621 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=19 Stats: 4525 lines in 190 files changed: 3194 ins; 718 del; 613 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From yzheng at openjdk.org Wed Sep 18 12:25:51 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 18 Sep 2024 12:25:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 12:52:03 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - CompressedKlassPointers::is_encodable shall be callable with -UseCCP > - Johan review feedback Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2358324621 From rkennke at openjdk.org Wed Sep 18 12:38:21 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Sep 2024 12:38:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 19:04:13 GMT, Chris Plummer wrote: >> I pulled your changes and I see one slight difference in the output. The following line is missing: >> >> `_metadata._compressed_klass: InstanceKlass for java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject` >> >> I realize that there is no `_metadata._compressed_klass` when you have compact headers, and that the Klass* is encoded in the `_mark` word, which is now looks something like this in the output: >> >> _mark: 16294762323640321 >> >> So you can say that the Klass* is embedded in the _mark work, but this isn't of much help to SA users. I think what is expected is that the visitor is passed a MetadataField object that when getValue() is called on it, the Klass mirror is returned. Maybe we need a new CompactKlassField type like we current have a NarrowKlassField field type, and it will do the decoding of the _mark work into a Klass. The current getKlass() is related to this. > > Thinking about this a bit more, maybe _mark needs to be a MetadataFile rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two seprate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case. Do you think this needs to be addressed before integration? And if so, could you help with implementation? Or could we do it after intergration? Then please file a follow-up issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1764976086 From rkennke at openjdk.org Wed Sep 18 12:59:25 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Sep 2024 12:59:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Mon, 9 Sep 2024 18:30:21 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with six additional commits since the last revision: >> >> - Print as warning when UCOH doesn't match in CDS archive >> - Improve initialization of mark-word in CDS ArchiveHeapWriter >> - Simplify getKlass() in SA >> - Simplify oopDesc::init_mark() >> - Get rid of forward_safe_* methods >> - GCForwarding touch-ups > > src/hotspot/share/oops/markWord.inline.hpp line 90: > >> 88: ShouldNotReachHere(); >> 89: return markWord(); >> 90: #endif > > Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits? Kindof. The problem is that klass_shift is larger than 31, and shifting with it would thus be UB and generate a compiler warning. I opted to simply not compile any of that code in 32bit builds. We could also define klass_shift differently on 32bit. Long-term (maybe with Lilliput2/4-byte-headers?) it would be nice to consolidate the header layout between 32 and 64 bit builds and not make any distinction anywhere. E.g. define markWord (or objectHeader?) in a single way, and use that to extract all the relevant stuff. It's not totally unlikely that we deprecate 32-bit builds before that can happen, though. > src/hotspot/share/oops/oop.inline.hpp line 90: > >> 88: } else { >> 89: return markWord::prototype(); >> 90: } > > Could this be unconditional since prototoype_header is initialized for all Klasses? yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765003983 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765006669 From rkennke at openjdk.org Wed Sep 18 13:23:44 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Sep 2024 13:23:44 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: JVMCI support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/bb641621..9ad2e62f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=19-20 Stats: 22 lines in 6 files changed: 16 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Wed Sep 18 14:00:25 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 18 Sep 2024 14:00:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 12:27:14 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix FullGCForwarding initialization > > src/hotspot/share/memory/classLoaderMetaspace.cpp line 87: > >> 85: klass_alignment_words, >> 86: "class arena"); >> 87: } > > As per my comment in the header file, change the code to this: > > ```c++ > if (class_context != nullptr) { > // ... Same as in PR > } else { > _class_space_arena = _non_class_space_arena; > } Rather not, see reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754330432 > src/hotspot/share/memory/classLoaderMetaspace.cpp line 118: > >> 116: #ifdef ASSERT >> 117: if (result.is_nonempty()) { >> 118: const bool in_class_arena = class_space_arena() != nullptr ? class_space_arena()->contains(result) : false; > > Unnecessary nullptr check if you take my suggestion, or you should switch to `have_class_space_arena`. See reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754335269 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765113297 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765113850 From cjplummer at openjdk.org Wed Sep 18 16:41:20 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 18 Sep 2024 16:41:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 12:35:28 GMT, Roman Kennke wrote: >> Thinking about this a bit more, maybe _mark needs to be a MetadataField rather than CInt. This is a kind of odd situation. Basically we have a CInt field that is more than just simple bits used as flags or small integers. It also gets you to the Klass*. Possibly SA should treat _mark is two separate fields; one that remains a CInt as it currently is and another that treats it as an encoded Klass* like the NarrowKlassField case. > > Do you think this needs to be addressed before integration? And if so, could you help with implementation? Or could we do it after intergration? Then please file a follow-up issue. Ok. I filed [JDK-8340396](https://bugs.openjdk.org/browse/JDK-8340396). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765387764 From coleenp at openjdk.org Thu Sep 19 00:04:45 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Sep 2024 00:04:45 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > JVMCI support src/hotspot/share/oops/compressedKlass.cpp line 242: > 240: } else { > 241: > 242: // Traditional (non-compact) header mode) Extra ) src/hotspot/share/oops/compressedKlass.hpp line 175: > 173: // 5b) if CDS=off: Calls initialize() - here, we have more freedom and, if we want, can choose an encoding > 174: // base that differs from the reservation base from step (4). That allows us, e.g., to later use > 175: // zero-based encoding. Not for this but is there really any benefit for zero based encoding for klass ids? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765888065 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765889975 From coleenp at openjdk.org Thu Sep 19 00:04:46 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Sep 2024 00:04:46 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Wed, 18 Sep 2024 12:56:16 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/oop.inline.hpp line 90: >> >>> 88: } else { >>> 89: return markWord::prototype(); >>> 90: } >> >> Could this be unconditional since prototoype_header is initialized for all Klasses? > > yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then. Yes, I saw that patch. I'm not sure I like the idea of cpu dependent code also doing the encoding. There were some C2 changes related to it that I didn't understand if that scheme required them. I don't see the down side to having the prototype header pre-encoded in the markWord. Seems simpler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1765893566 From stefank at openjdk.org Thu Sep 19 05:06:51 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Sep 2024 05:06:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Wed, 18 Sep 2024 23:59:39 GMT, Coleen Phillimore wrote: >> yes, but there is ongoing effort (at Oracle) to get rid of ```Klass::_prototype_header``` altogether. Let's wait for that and see how it looks then. > > Yes, I saw that patch. I'm not sure I like the idea of cpu dependent code also doing the encoding. There were some C2 changes related to it that I didn't understand if that scheme required them. I don't see the down side to having the prototype header pre-encoded in the markWord. Seems simpler. We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766163092 From stefank at openjdk.org Thu Sep 19 05:53:48 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Sep 2024 05:53:48 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > JVMCI support src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787: > 785: // The gap is always equal to min-fill-size, so nothing to do. > 786: return; > 787: } Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value: void PSParallelCompact::fill_dense_prefix_end(SpaceId id) { // Comparing two sizes to decide if filling is required: // // The size of the filler (min-obj-size) is 2 heap words with the default // MinObjAlignment, since both markword and klass take 1 heap word. // // The size of the gap (if any) right before dense-prefix-end is // MinObjAlignment. // // Need to fill in the gap only if it's smaller than min-obj-size, and the // filler obj will extend to next region. // Note: If min-fill-size decreases to 1, this whole method becomes redundant. if (UseCompactObjectHeaders) { // The gap is always equal to min-fill-size, so nothing to do. return; } assert(CollectedHeap::min_fill_size() >= 2, "inv"); src/hotspot/share/oops/compressedKlass.cpp line 231: > 229: // The reason is that we want to avoid, if possible, shifts larger than > 230: // a cacheline size. > 231: _base = addr; Why is this important? src/hotspot/share/oops/compressedKlass.hpp line 261: > 259: } > 260: > 261: }; Missing blank line before `#endif` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766185665 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766192688 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766193355 From stefank at openjdk.org Thu Sep 19 05:53:49 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Sep 2024 05:53:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com> On Thu, 19 Sep 2024 05:35:34 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787: > >> 785: // The gap is always equal to min-fill-size, so nothing to do. >> 786: return; >> 787: } > > Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value: > > void PSParallelCompact::fill_dense_prefix_end(SpaceId id) { > // Comparing two sizes to decide if filling is required: > // > // The size of the filler (min-obj-size) is 2 heap words with the default > // MinObjAlignment, since both markword and klass take 1 heap word. > // > // The size of the gap (if any) right before dense-prefix-end is > // MinObjAlignment. > // > // Need to fill in the gap only if it's smaller than min-obj-size, and the > // filler obj will extend to next region. > > // Note: If min-fill-size decreases to 1, this whole method becomes redundant. > if (UseCompactObjectHeaders) { > // The gap is always equal to min-fill-size, so nothing to do. > return; > } > assert(CollectedHeap::min_fill_size() >= 2, "inv"); Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766186545 From shade at openjdk.org Thu Sep 19 05:55:45 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Sep 2024 05:55:45 GMT Subject: RFR: 8340418: GHA: MacOS AArch64 bundles can be removed prematurely Message-ID: `remove-bundles` step does not depend on `test-macos-aarch64`, which means it can run before macos-aarch64 tests start to run, which would fail those steps. This is not frequent, but will happen if macos-aarch64 runners are lagging behind to pick up the jobs. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/21080/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340418 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21080/head:pull/21080 PR: https://git.openjdk.org/jdk/pull/21080 From mli at openjdk.org Thu Sep 19 08:38:55 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 08:38:55 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF Message-ID: Hi, Can you help to review this patch? Thanks! This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. ### Test test/jdk/jdk/incubator/vector ### Performance data on bananapi Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement -- | -- | -- | -- | -- | -- | -- | -- | -- | -- Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 Double128Vector.SIN | 1024 | avgt | 10 | 166240.988 | 512.253 | 287741.373 | 2089.286 | ns/op | 1.731 Double128Vector.SINH | 1024 | avgt | 10 | 196233.614 | 225.88 | 221493.573 | 60941.438 | ns/op | 1.129 Double128Vector.TAN | 1024 | avgt | 10 | 203347.384 | 267.385 | 372912.183 | 2093.675 | ns/op | 1.834 Double128Vector.TANH | 1024 | avgt | 10 | 195587.19 | 5260.844 | 190723.4 | 873.135 | ns/op | 0.975 Double256Vector.ACOS | 1024 | avgt | 10 | 55282.885 | 8.888 | 138468.959 | 1342.937 | ns/op | 2.505 Double256Vector.ASIN | 1024 | avgt | 10 | 51424.997 | 22.614 | 141245.24 | 3213.405 | ns/op | 2.747 Double256Vector.ATAN | 1024 | avgt | 10 | 70385.397 | 14.196 | 210226.648 | 897.412 | ns/op | 2.987 Double256Vector.ATAN2 | 1024 | avgt | 10 | 83098.264 | 120.424 | 373363.523 | 3093.761 | ns/op | 4.493 Double256Vector.CBRT | 1024 | avgt | 10 | 72695.917 | 28.785 | 250843.027 | 869.34 | ns/op | 3.451 Double256Vector.COS | 1024 | avgt | 10 | 77373.4 | 10.275 | 249779.557 | 1143.93 | ns/op | 3.228 Double256Vector.COSH | 1024 | avgt | 10 | 95626.561 | 169.093 | 135295.836 | 26164.804 | ns/op | 1.415 Double256Vector.EXP | 1024 | avgt | 10 | 57013.105 | 25.681 | 169211.888 | 1723.985 | ns/op | 2.968 Double256Vector.EXPM1 | 1024 | avgt | 10 | 89929.364 | 172.868 | 189713.959 | 619.662 | ns/op | 2.11 Double256Vector.HYPOT | 1024 | avgt | 10 | 58179.576 | 72.265 | 253002.315 | 1413.97 | ns/op | 4.349 Double256Vector.LOG | 1024 | avgt | 10 | 55274.107 | 6.781 | 199552.499 | 1070.838 | ns/op | 3.61 Double256Vector.LOG10 | 1024 | avgt | 10 | 58321.206 | 3.046 | 219497.134 | 1784.676 | ns/op | 3.764 Double256Vector.LOG1P | 1024 | avgt | 10 | 59457.661 | 4.266 | 248897.335 | 1101.141 | ns/op | 4.186 Double256Vector.POW | 1024 | avgt | 10 | 161727.792 | 283.278 | 389901.211 | 5128.643 | ns/op | 2.411 Double256Vector.SIN | 1024 | avgt | 10 | 82028.764 | 163.402 | 229585.318 | 2284.46 | ns/op | 2.799 Double256Vector.SINH | 1024 | avgt | 10 | 95533.939 | 144.219 | 138338.01 | 32257.269 | ns/op | 1.448 Double256Vector.TAN | 1024 | avgt | 10 | 100587.595 | 175.454 | 255335.96 | 2392.867 | ns/op | 2.538 Double256Vector.TANH | 1024 | avgt | 10 | 122826.824 | 8132.31 | 116587.352 | 20456.614 | ns/op | 0.949 Double512Vector.ACOS | 1024 | avgt | 10 | 100644.726 | 6559.453 | 90596.17 | 6201.774 | ns/op | 0.9 Double512Vector.ASIN | 1024 | avgt | 10 | 97781.73 | 6454.561 | 81923.501 | 6875.259 | ns/op | 0.838 Double512Vector.ATAN | 1024 | avgt | 10 | 230365.297 | 5657.262 | 231136.108 | 8201.677 | ns/op | 1.003 Double512Vector.ATAN2 | 1024 | avgt | 10 | 330644.739 | 965.308 | 334507.514 | 1871.147 | ns/op | 1.012 Double512Vector.CBRT | 1024 | avgt | 10 | 269499.416 | 7578.3 | 275058.533 | 2931.999 | ns/op | 1.021 Double512Vector.COS | 1024 | avgt | 10 | 250239.661 | 8717.098 | 251643.64 | 5974.845 | ns/op | 1.006 Double512Vector.COSH | 1024 | avgt | 10 | 130896.571 | 3149.555 | 116148.85 | 19419.192 | ns/op | 0.887 Double512Vector.EXP | 1024 | avgt | 10 | 167358.383 | 4017.309 | 163777.077 | 9441.332 | ns/op | 0.979 Double512Vector.EXPM1 | 1024 | avgt | 10 | 180627.099 | 6239.875 | 181451.788 | 2833.293 | ns/op | 1.005 Double512Vector.HYPOT | 1024 | avgt | 10 | 259838.022 | 2413.253 | 253563.622 | 5666.461 | ns/op | 0.976 Double512Vector.LOG | 1024 | avgt | 10 | 214492.394 | 8551.06 | 223659.532 | 4634.475 | ns/op | 1.043 Double512Vector.LOG10 | 1024 | avgt | 10 | 237482.746 | 5504.954 | 241056.068 | 3773.962 | ns/op | 1.015 Double512Vector.LOG1P | 1024 | avgt | 10 | 259562.363 | 6983.428 | 255542.226 | 6799.872 | ns/op | 0.985 Double512Vector.POW | 1024 | avgt | 10 | 409067.718 | 1031.843 | 415598.626 | 1333.94 | ns/op | 1.016 Double512Vector.SIN | 1024 | avgt | 10 | 233720.922 | 9117.177 | 237166.138 | 5740.104 | ns/op | 1.015 Double512Vector.SINH | 1024 | avgt | 10 | 106110.446 | 8082.622 | 120441.14 | 19807.6 | ns/op | 1.135 Double512Vector.TAN | 1024 | avgt | 10 | 286363.576 | 5171.85 | 289463.344 | 5786.435 | ns/op | 1.011 Double512Vector.TANH | 1024 | avgt | 10 | 55621.25 | 1751.435 | 54999.583 | 114.941 | ns/op | 0.989 Double64Vector.ACOS | 1024 | avgt | 10 | 440775.699 | 2196.779 | 448951.428 | 1820.252 | ns/op | 1.019 Double64Vector.ASIN | 1024 | avgt | 10 | 463051.606 | 2394.98 | 454351.539 | 2086.492 | ns/op | 0.981 Double64Vector.ATAN | 1024 | avgt | 10 | 544190.664 | 4013.885 | 546309.02 | 3440.376 | ns/op | 1.004 Double64Vector.ATAN2 | 1024 | avgt | 10 | 799967.835 | 3488.851 | 812483.613 | 2421.999 | ns/op | 1.016 Double64Vector.CBRT | 1024 | avgt | 10 | 618953.967 | 5293.167 | 622328.702 | 2301.048 | ns/op | 1.005 Double64Vector.COS | 1024 | avgt | 10 | 574667.991 | 2894.881 | 604963.23 | 12128.549 | ns/op | 1.053 Double64Vector.COSH | 1024 | avgt | 10 | 480884.659 | 3050.01 | 474405.728 | 2223.766 | ns/op | 0.987 Double64Vector.EXP | 1024 | avgt | 10 | 476743.952 | 1468.7 | 493014.212 | 2879.845 | ns/op | 1.034 Double64Vector.EXPM1 | 1024 | avgt | 10 | 522048.987 | 2879.475 | 505978.67 | 1825.956 | ns/op | 0.969 Double64Vector.HYPOT | 1024 | avgt | 10 | 713841.457 | 2816.621 | 716284.872 | 7024.984 | ns/op | 1.003 Double64Vector.LOG | 1024 | avgt | 10 | 523702.517 | 1849.651 | 525498.61 | 1122.938 | ns/op | 1.003 Double64Vector.LOG10 | 1024 | avgt | 10 | 539968.004 | 2445.033 | 541415.051 | 2966.057 | ns/op | 1.003 Double64Vector.LOG1P | 1024 | avgt | 10 | 556206.02 | 3156.961 | 554613.942 | 2628.038 | ns/op | 0.997 Double64Vector.POW | 1024 | avgt | 10 | 931275.694 | 5378.585 | 914787.042 | 11244.374 | ns/op | 0.982 Double64Vector.SIN | 1024 | avgt | 10 | 620118.172 | 3805.705 | 553147.004 | 2265.843 | ns/op | 0.892 Double64Vector.SINH | 1024 | avgt | 10 | 504218.91 | 2259.924 | 482680.497 | 5218.21 | ns/op | 0.957 Double64Vector.TAN | 1024 | avgt | 10 | 620591.643 | 5541.53 | 622098.336 | 4892.394 | ns/op | 1.002 Double64Vector.TANH | 1024 | avgt | 10 | 438766.135 | 4313.069 | 426783.749 | 5986.632 | ns/op | 0.973 DoubleMaxVector.ACOS | 1024 | avgt | 10 | 55281.88 | 5.819 | 152707.139 | 2337.434 | ns/op | 2.762 DoubleMaxVector.ASIN | 1024 | avgt | 10 | 51632.365 | 20.723 | 152958.169 | 2530.258 | ns/op | 2.962 DoubleMaxVector.ATAN | 1024 | avgt | 10 | 70393.309 | 7.502 | 225146.6 | 4836.393 | ns/op | 3.198 DoubleMaxVector.ATAN2 | 1024 | avgt | 10 | 83049.389 | 131.221 | 376129.104 | 2973.54 | ns/op | 4.529 DoubleMaxVector.CBRT | 1024 | avgt | 10 | 73401.993 | 20.547 | 252789.351 | 1322.396 | ns/op | 3.444 DoubleMaxVector.COS | 1024 | avgt | 10 | 77388.046 | 8.768 | 252428.563 | 4605.328 | ns/op | 3.262 DoubleMaxVector.COSH | 1024 | avgt | 10 | 95373.866 | 167.177 | 145355.624 | 35146.538 | ns/op | 1.524 DoubleMaxVector.EXP | 1024 | avgt | 10 | 57910.881 | 11.031 | 183133.879 | 3721.502 | ns/op | 3.162 DoubleMaxVector.EXPM1 | 1024 | avgt | 10 | 89968.248 | 180.822 | 199712.477 | 2009.862 | ns/op | 2.22 DoubleMaxVector.HYPOT | 1024 | avgt | 10 | 59064.115 | 186.157 | 253275.967 | 1479.124 | ns/op | 4.288 DoubleMaxVector.LOG | 1024 | avgt | 10 | 53685.913 | 4.08 | 202019.279 | 1174.832 | ns/op | 3.763 DoubleMaxVector.LOG10 | 1024 | avgt | 10 | 58333.057 | 4.644 | 223237.023 | 2682.561 | ns/op | 3.827 DoubleMaxVector.LOG1P | 1024 | avgt | 10 | 59455.511 | 4.493 | 248216.075 | 4200.623 | ns/op | 4.175 DoubleMaxVector.POW | 1024 | avgt | 10 | 161793.312 | 355.543 | 395000.995 | 4070.581 | ns/op | 2.441 DoubleMaxVector.SIN | 1024 | avgt | 10 | 82045.108 | 178.173 | 232964.02 | 3351.878 | ns/op | 2.839 DoubleMaxVector.SINH | 1024 | avgt | 10 | 95557.571 | 171.167 | 139434.904 | 33020.695 | ns/op | 1.459 DoubleMaxVector.TAN | 1024 | avgt | 10 | 99139.084 | 170.106 | 255665.125 | 1463.226 | ns/op | 2.579 DoubleMaxVector.TANH | 1024 | avgt | 10 | 122556.944 | 7304.643 | 112638.697 | 22789.428 | ns/op | 0.919 DoubleScalar.ACOS | 1024 | avgt | 10 | 35364.49 | 43.834 | 35391.461 | 11.475 | ns/op | 1.001 DoubleScalar.ASIN | 1024 | avgt | 10 | 36020.676 | 41.123 | 36040.44 | 22.284 | ns/op | 1.001 DoubleScalar.ATAN | 1024 | avgt | 10 | 100104.331 | 135.729 | 102039.921 | 286.803 | ns/op | 1.019 DoubleScalar.ATAN2 | 1024 | avgt | 10 | 163987.639 | 239.624 | 165832.456 | 1865.186 | ns/op | 1.011 DoubleScalar.CBRT | 1024 | avgt | 10 | 144175.051 | 169.152 | 144177.588 | 175.837 | ns/op | 1 DoubleScalar.COS | 1024 | avgt | 10 | 129137.254 | 186.072 | 129187.403 | 164.344 | ns/op | 1 DoubleScalar.COSH | 1024 | avgt | 10 | 65408.411 | 158.758 | 65469.654 | 302.387 | ns/op | 1.001 DoubleScalar.EXP | 1024 | avgt | 10 | 66358.519 | 15.942 | 66370.088 | 13.886 | ns/op | 1 DoubleScalar.EXPM1 | 1024 | avgt | 10 | 84449.659 | 20.205 | 84443.216 | 17.539 | ns/op | 1 DoubleScalar.HYPOT | 1024 | avgt | 10 | 98996.854 | 149.906 | 99114.226 | 247.392 | ns/op | 1.001 DoubleScalar.LOG | 1024 | avgt | 10 | 92296.061 | 84.554 | 92362.323 | 127.4 | ns/op | 1.001 DoubleScalar.LOG10 | 1024 | avgt | 10 | 108959.603 | 214.845 | 109177.708 | 151.172 | ns/op | 1.002 DoubleScalar.LOG1P | 1024 | avgt | 10 | 133745.827 | 189.726 | 133626.747 | 159.786 | ns/op | 0.999 DoubleScalar.POW | 1024 | avgt | 10 | 245735.03 | 392.669 | 246363.909 | 776.007 | ns/op | 1.003 DoubleScalar.SIN | 1024 | avgt | 10 | 112985.666 | 211.564 | 113015.922 | 93.048 | ns/op | 1 DoubleScalar.SINH | 1024 | avgt | 10 | 65009.526 | 547.157 | 65443.714 | 150.434 | ns/op | 1.007 DoubleScalar.TAN | 1024 | avgt | 10 | 163437.236 | 157.673 | 163196.802 | 196.316 | ns/op | 0.999 DoubleScalar.TANH | 1024 | avgt | 10 | 15174.949 | 7.999 | 15178.266 | 19.863 | ns/op | 1 Float128Vector.ACOS | 1024 | avgt | 10 | 43372.933 | 5.055 | 126575.586 | 976.159 | ns/op | 2.918 Float128Vector.ASIN | 1024 | avgt | 10 | 38632.619 | 1.743 | 127126.175 | 1368.112 | ns/op | 3.291 Float128Vector.ATAN | 1024 | avgt | 10 | 56269.042 | 3.274 | 188537.782 | 1465.567 | ns/op | 3.351 Float128Vector.ATAN2 | 1024 | avgt | 10 | 64863.602 | 9.184 | 289789.784 | 1933.189 | ns/op | 4.468 Float128Vector.CBRT | 1024 | avgt | 10 | 60648.572 | 30.499 | 219496.505 | 2628.005 | ns/op | 3.619 Float128Vector.COS | 1024 | avgt | 10 | 90296.6 | 173.89 | 193875.308 | 2878.795 | ns/op | 2.147 Float128Vector.COSH | 1024 | avgt | 10 | 72513.407 | 13.428 | 134362.41 | 28085.258 | ns/op | 1.853 Float128Vector.EXP | 1024 | avgt | 10 | 32520.847 | 6.845 | 158283.434 | 1092.762 | ns/op | 4.867 Float128Vector.EXPM1 | 1024 | avgt | 10 | 65130.005 | 3.498 | 186841.627 | 1140.313 | ns/op | 2.869 Float128Vector.HYPOT | 1024 | avgt | 10 | 52240.243 | 4.423 | 228928.31 | 1385.126 | ns/op | 4.382 Float128Vector.LOG | 1024 | avgt | 10 | 44080.307 | 2.549 | 186830.712 | 797.576 | ns/op | 4.238 Float128Vector.LOG10 | 1024 | avgt | 10 | 45302.969 | 7.095 | 189605.302 | 2126.429 | ns/op | 4.185 Float128Vector.LOG1P | 1024 | avgt | 10 | 47599.582 | 3.822 | 194058.394 | 2620.35 | ns/op | 4.077 Float128Vector.POW | 1024 | avgt | 10 | 118329.731 | 157.834 | 375914.2 | 2800.253 | ns/op | 3.177 Float128Vector.SIN | 1024 | avgt | 10 | 96545.285 | 409.639 | 190830.529 | 1511.452 | ns/op | 1.977 Float128Vector.SINH | 1024 | avgt | 10 | 67999.296 | 8.793 | 134817.031 | 28316.519 | ns/op | 1.983 Float128Vector.TAN | 1024 | avgt | 10 | 105051.902 | 193.021 | 236690.576 | 6686.38 | ns/op | 2.253 Float128Vector.TANH | 1024 | avgt | 10 | 107938.486 | 1593.331 | 107867.708 | 1037.358 | ns/op | 0.999 Float256Vector.ACOS | 1024 | avgt | 10 | 21993.336 | 0.945 | 90171.186 | 765.896 | ns/op | 4.1 Float256Vector.ASIN | 1024 | avgt | 10 | 19176.439 | 4.288 | 91491.757 | 946.887 | ns/op | 4.771 Float256Vector.ATAN | 1024 | avgt | 10 | 28573.58 | 1.788 | 153126.232 | 1354.054 | ns/op | 5.359 Float256Vector.ATAN2 | 1024 | avgt | 10 | 32809.207 | 57.366 | 241229.586 | 2703.039 | ns/op | 7.352 Float256Vector.CBRT | 1024 | avgt | 10 | 30349.65 | 5.52 | 195162.623 | 2631.134 | ns/op | 6.43 Float256Vector.COS | 1024 | avgt | 10 | 45629.146 | 6.614 | 185366.17 | 1616.6 | ns/op | 4.062 Float256Vector.COSH | 1024 | avgt | 10 | 36923.595 | 2.135 | 108690.335 | 13921.018 | ns/op | 2.944 Float256Vector.EXP | 1024 | avgt | 10 | 16170.263 | 2.046 | 125594.096 | 1033.554 | ns/op | 7.767 Float256Vector.EXPM1 | 1024 | avgt | 10 | 32608.2 | 5.484 | 129709.448 | 993.492 | ns/op | 3.978 Float256Vector.HYPOT | 1024 | avgt | 10 | 27921.801 | 1.528 | 190117.16 | 1454.543 | ns/op | 6.809 Float256Vector.LOG | 1024 | avgt | 10 | 22076.681 | 2.329 | 134540.724 | 1704.931 | ns/op | 6.094 Float256Vector.LOG10 | 1024 | avgt | 10 | 23064.284 | 2.37 | 159962.122 | 2503.179 | ns/op | 6.935 Float256Vector.LOG1P | 1024 | avgt | 10 | 23835.965 | 2.04 | 194624.332 | 4779.995 | ns/op | 8.165 Float256Vector.POW | 1024 | avgt | 10 | 59593.468 | 74.705 | 317616.881 | 1183.352 | ns/op | 5.33 Float256Vector.SIN | 1024 | avgt | 10 | 48733.012 | 19.4 | 169500.443 | 2768.932 | ns/op | 3.478 Float256Vector.SINH | 1024 | avgt | 10 | 33625.182 | 1.423 | 124512.293 | 1771.11 | ns/op | 3.703 Float256Vector.TAN | 1024 | avgt | 10 | 54313.62 | 14.978 | 215172.493 | 1753.706 | ns/op | 3.962 Float256Vector.TANH | 1024 | avgt | 10 | 61708.469 | 1605.348 | 63690.609 | 796.163 | ns/op | 1.032 Float512Vector.ACOS | 1024 | avgt | 10 | 93820.934 | 3011.58 | 90663.418 | 2027.372 | ns/op | 0.966 Float512Vector.ASIN | 1024 | avgt | 10 | 95866.984 | 3057.351 | 97612.203 | 3787.454 | ns/op | 1.018 Float512Vector.ATAN | 1024 | avgt | 10 | 167859.888 | 4240.703 | 167247.975 | 4300.418 | ns/op | 0.996 Float512Vector.ATAN2 | 1024 | avgt | 10 | 255441.315 | 685.737 | 254700.612 | 4896.306 | ns/op | 0.997 Float512Vector.CBRT | 1024 | avgt | 10 | 214410.72 | 931.01 | 214285.796 | 1383.406 | ns/op | 0.999 Float512Vector.COS | 1024 | avgt | 10 | 196689.274 | 1880.854 | 197309.067 | 1784.865 | ns/op | 1.003 Float512Vector.COSH | 1024 | avgt | 10 | 104335.896 | 561.089 | 88993.056 | 1788.606 | ns/op | 0.853 Float512Vector.EXP | 1024 | avgt | 10 | 135852.89 | 2981.107 | 135877.338 | 2846.752 | ns/op | 1 Float512Vector.EXPM1 | 1024 | avgt | 10 | 152498.16 | 2995.351 | 153719.922 | 2343.672 | ns/op | 1.008 Float512Vector.HYPOT | 1024 | avgt | 10 | 188872.565 | 802.938 | 188659.105 | 505.853 | ns/op | 0.999 Float512Vector.LOG | 1024 | avgt | 10 | 159618.453 | 2347.331 | 159789.006 | 3077.534 | ns/op | 1.001 Float512Vector.LOG10 | 1024 | avgt | 10 | 177141.543 | 2208.144 | 173862.555 | 7986.955 | ns/op | 0.981 Float512Vector.LOG1P | 1024 | avgt | 10 | 201767.835 | 2097.682 | 194773.996 | 3261.783 | ns/op | 0.965 Float512Vector.POW | 1024 | avgt | 10 | 340428.997 | 898.57 | 339608.679 | 2319.682 | ns/op | 0.998 Float512Vector.SIN | 1024 | avgt | 10 | 182644.272 | 2827.997 | 183512.561 | 3230.558 | ns/op | 1.005 Float512Vector.SINH | 1024 | avgt | 10 | 88864.538 | 856.677 | 96766.798 | 4680.862 | ns/op | 1.089 Float512Vector.TAN | 1024 | avgt | 10 | 230591.607 | 2406.274 | 235481.617 | 2062.326 | ns/op | 1.021 Float512Vector.TANH | 1024 | avgt | 10 | 41323.35 | 1108.87 | 41397.969 | 105.838 | ns/op | 1.002 Float64Vector.ACOS | 1024 | avgt | 10 | 87808.157 | 135.816 | 197215.577 | 1427.244 | ns/op | 2.246 Float64Vector.ASIN | 1024 | avgt | 10 | 79126.845 | 9.019 | 197556.29 | 786.402 | ns/op | 2.497 Float64Vector.ATAN | 1024 | avgt | 10 | 112334.153 | 161.759 | 262670.28 | 1106.929 | ns/op | 2.338 Float64Vector.ATAN2 | 1024 | avgt | 10 | 132755.668 | 148.942 | 422308.023 | 1739.683 | ns/op | 3.181 Float64Vector.CBRT | 1024 | avgt | 10 | 121393.777 | 462.316 | 311727.38 | 2783.373 | ns/op | 2.568 Float64Vector.COS | 1024 | avgt | 10 | 180332.5 | 204.792 | 311139.369 | 2435.05 | ns/op | 1.725 Float64Vector.COSH | 1024 | avgt | 10 | 145071.014 | 281.11 | 219063.334 | 1330.185 | ns/op | 1.51 Float64Vector.EXP | 1024 | avgt | 10 | 64474.087 | 18.916 | 222943.443 | 2074.818 | ns/op | 3.458 Float64Vector.EXPM1 | 1024 | avgt | 10 | 128611.56 | 230.073 | 242737.624 | 1997.438 | ns/op | 1.887 Float64Vector.HYPOT | 1024 | avgt | 10 | 104683.692 | 161.234 | 324578.297 | 2702.814 | ns/op | 3.101 Float64Vector.LOG | 1024 | avgt | 10 | 88124.496 | 142.168 | 252264.027 | 536.035 | ns/op | 2.863 Float64Vector.LOG10 | 1024 | avgt | 10 | 95184.783 | 184.6 | 270674.746 | 1399.203 | ns/op | 2.844 Float64Vector.LOG1P | 1024 | avgt | 10 | 91969.404 | 1086.102 | 310777.655 | 2490.714 | ns/op | 3.379 Float64Vector.POW | 1024 | avgt | 10 | 237248.014 | 1684.478 | 472070.731 | 2933.214 | ns/op | 1.99 Float64Vector.SIN | 1024 | avgt | 10 | 194778.558 | 470.935 | 281942.775 | 1400.795 | ns/op | 1.448 Float64Vector.SINH | 1024 | avgt | 10 | 137944.677 | 202.705 | 222200.113 | 1312.19 | ns/op | 1.611 Float64Vector.TAN | 1024 | avgt | 10 | 212713.608 | 218.316 | 313379.409 | 2596.888 | ns/op | 1.473 Float64Vector.TANH | 1024 | avgt | 10 | 173926.377 | 1685.093 | 174629.554 | 3082.909 | ns/op | 1.004 FloatMaxVector.ACOS | 1024 | avgt | 10 | 21889.905 | 39.906 | 90252.786 | 418.764 | ns/op | 4.123 FloatMaxVector.ASIN | 1024 | avgt | 10 | 18793.467 | 4.566 | 90741.587 | 741.291 | ns/op | 4.828 FloatMaxVector.ATAN | 1024 | avgt | 10 | 28496.993 | 6.548 | 153581.577 | 1744.674 | ns/op | 5.389 FloatMaxVector.ATAN2 | 1024 | avgt | 10 | 33658.989 | 3.092 | 258396.05 | 5256.453 | ns/op | 7.677 FloatMaxVector.CBRT | 1024 | avgt | 10 | 30350.281 | 1.956 | 197139.203 | 2129.485 | ns/op | 6.495 FloatMaxVector.COS | 1024 | avgt | 10 | 45628.863 | 3.576 | 187231.562 | 1821.847 | ns/op | 4.103 FloatMaxVector.COSH | 1024 | avgt | 10 | 36925.011 | 5.202 | 108522.288 | 13952.184 | ns/op | 2.939 FloatMaxVector.EXP | 1024 | avgt | 10 | 16173.603 | 1.355 | 126495.517 | 621.715 | ns/op | 7.821 FloatMaxVector.EXPM1 | 1024 | avgt | 10 | 32651.571 | 16.621 | 129689.32 | 2807.684 | ns/op | 3.972 FloatMaxVector.HYPOT | 1024 | avgt | 10 | 28246.148 | 2.652 | 190196.415 | 1919.742 | ns/op | 6.734 FloatMaxVector.LOG | 1024 | avgt | 10 | 22078.034 | 5.796 | 137138.837 | 3034.756 | ns/op | 6.212 FloatMaxVector.LOG10 | 1024 | avgt | 10 | 23840.747 | 6.694 | 164126.237 | 2423.198 | ns/op | 6.884 FloatMaxVector.LOG1P | 1024 | avgt | 10 | 22993.078 | 5.389 | 190345.701 | 1427.37 | ns/op | 8.278 FloatMaxVector.POW | 1024 | avgt | 10 | 58727.04 | 133.816 | 316392.473 | 1713.258 | ns/op | 5.388 FloatMaxVector.SIN | 1024 | avgt | 10 | 48729.964 | 4.439 | 168993.476 | 2234.287 | ns/op | 3.468 FloatMaxVector.SINH | 1024 | avgt | 10 | 33635.008 | 2.951 | 117198.021 | 2609.295 | ns/op | 3.484 FloatMaxVector.TAN | 1024 | avgt | 10 | 54314.082 | 14.057 | 213847.082 | 1390.695 | ns/op | 3.937 FloatMaxVector.TANH | 1024 | avgt | 10 | 65545.343 | 1419.074 | 65362.648 | 1729.148 | ns/op | 0.997 FloatScalar.ACOS | 1024 | avgt | 10 | 36607.495 | 4.656 | 36661.257 | 20.306 | ns/op | 1.001 FloatScalar.ASIN | 1024 | avgt | 10 | 37281.012 | 28.006 | 37272.249 | 46.647 | ns/op | 1 FloatScalar.ATAN | 1024 | avgt | 10 | 101949.284 | 327.101 | 103939.277 | 166.274 | ns/op | 1.02 FloatScalar.ATAN2 | 1024 | avgt | 10 | 165461.209 | 1727.043 | 163270.286 | 593.568 | ns/op | 0.987 FloatScalar.CBRT | 1024 | avgt | 10 | 148653.826 | 166.069 | 148638.661 | 171.44 | ns/op | 1 FloatScalar.COS | 1024 | avgt | 10 | 129975.842 | 204.494 | 129889.093 | 123.915 | ns/op | 0.999 FloatScalar.COSH | 1024 | avgt | 10 | 67462.124 | 25.755 | 67761.353 | 12.415 | ns/op | 1.004 FloatScalar.EXP | 1024 | avgt | 10 | 67723.964 | 8.617 | 67720.157 | 15.651 | ns/op | 1 FloatScalar.EXPM1 | 1024 | avgt | 10 | 85058.759 | 97.872 | 84612.5 | 16.527 | ns/op | 0.995 FloatScalar.HYPOT | 1024 | avgt | 10 | 99875.247 | 713.526 | 99915.975 | 607.926 | ns/op | 1 FloatScalar.LOG | 1024 | avgt | 10 | 94004.039 | 20.602 | 93571.942 | 124.254 | ns/op | 0.995 FloatScalar.LOG10 | 1024 | avgt | 10 | 110012.901 | 232.67 | 110132.542 | 476.101 | ns/op | 1.001 FloatScalar.LOG1P | 1024 | avgt | 10 | 134646.067 | 809.2 | 134554.613 | 651.85 | ns/op | 0.999 FloatScalar.POW | 1024 | avgt | 10 | 246303.685 | 269.215 | 246268.844 | 294.437 | ns/op | 1 FloatScalar.SIN | 1024 | avgt | 10 | 115767.708 | 300.899 | 116114.497 | 209.168 | ns/op | 1.003 FloatScalar.SINH | 1024 | avgt | 10 | 68118.234 | 190.657 | 68973.513 | 289.182 | ns/op | 1.013 FloatScalar.TAN | 1024 | avgt | 10 | 164639.016 | 323.546 | 164428.942 | 175.806 | ns/op | 0.999 FloatScalar.TANH | 1024 | avgt | 10 | 17730.106 | 10.645 | 17730.258 | 9.184 | ns/op | 1 ------------- Commit messages: - fix make warning - Initial commit Changes: https://git.openjdk.org/jdk/pull/21083/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320500 Stats: 247 lines in 14 files changed: 202 ins; 0 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Thu Sep 19 08:38:55 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 08:38:55 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: <8CEveiLA-SQY0Lsf4JT0Fc-X8i81jcq69FTK2EWmq3Y=.407ee338-5201-443b-a7f4-699c6d02b1df@github.com> On Thu, 19 Sep 2024 08:32:38 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hi @magicus , could you please have a look at the make part? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2360366938 From mli at openjdk.org Thu Sep 19 10:32:50 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 10:32:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 13:23:44 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > JVMCI support src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2529: > 2527: } > 2528: __ decode_klass_not_null(result); > 2529: } else { Could this if/else block be replaced with a simple call of load_klass(...)? src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 3522: > 3520: { > 3521: __ movptr(result, Address(obj, oopDesc::klass_offset_in_bytes())); > 3522: } Could this if/else block be replaced with a simple call of load_klass(...)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766587136 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766582255 From rcastanedalo at openjdk.org Thu Sep 19 11:02:50 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 19 Sep 2024 11:02:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 08:04:43 GMT, Roberto Casta?eda Lozano wrote: > I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version. What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360673405 From yzheng at openjdk.org Thu Sep 19 11:12:49 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 19 Sep 2024 11:12:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Thu, 19 Sep 2024 05:03:42 GMT, Stefan Karlsson wrote: >> Yes, I saw that patch. I'm not sure I like the idea of cpu dependent code also doing the encoding. There were some C2 changes related to it that I didn't understand if that scheme required them. I don't see the down side to having the prototype header pre-encoded in the markWord. Seems simpler. > > We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler. Could you please point me to the C2 change? Is it going to be integrated in this PR? We in Graal have not yet adopted `Klass::_prototype_header` and will hold if you decide to get rid of it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766642585 From stuefe at openjdk.org Thu Sep 19 11:39:50 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 11:39:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 23:49:34 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/hotspot/share/oops/compressedKlass.cpp line 242: > >> 240: } else { >> 241: >> 242: // Traditional (non-compact) header mode) > > Extra ) Will fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766676702 From rkennke at openjdk.org Thu Sep 19 11:52:34 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Sep 2024 11:52:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v22] In-Reply-To: References: Message-ID: <0mWQW50x4UNwdsRE94w3rZVGnppxQeR9fbe4eUrAGtM=.cca89805-ca82-4605-bc11-4f9ac53d2b90@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Simplify LIR_Assembler::emit_load_klass() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/9ad2e62f..b25a4b69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=20-21 Stats: 28 lines in 2 files changed: 0 ins; 26 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Sep 19 11:52:34 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Sep 2024 11:52:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 11:00:20 GMT, Roberto Casta?eda Lozano wrote: > > I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version. > > What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers? Yes, that sounds like a good improvement! It'd also clean up C2 considerably - right now there are many places in C2 that rely on klass_offset_in_bytes(). Getting rid of them all would be great, but also seems like a major effort. Could you file an issue to track that future work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360756796 From rkennke at openjdk.org Thu Sep 19 11:52:37 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Sep 2024 11:52:37 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 10:29:11 GMT, Hamlin Li wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2529: > >> 2527: } >> 2528: __ decode_klass_not_null(result); >> 2529: } else { > > Could this if/else block be replaced with a simple call of load_klass(...)? Yes, will do. > src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 3522: > >> 3520: { >> 3521: __ movptr(result, Address(obj, oopDesc::klass_offset_in_bytes())); >> 3522: } > > Could this if/else block be replaced with a simple call of load_klass(...)? Yes, will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766689169 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766689004 From stuefe at openjdk.org Thu Sep 19 11:52:38 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 11:52:38 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 05:44:42 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/hotspot/share/oops/compressedKlass.cpp line 231: > >> 229: // The reason is that we want to avoid, if possible, shifts larger than >> 230: // a cacheline size. >> 231: _base = addr; > > Why is this important? It lessens the cache effects of Klass hyperaligning. > src/hotspot/share/oops/compressedKlass.hpp line 261: > >> 259: } >> 260: >> 261: }; > > Missing blank line before `#endif` Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766684016 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766684491 From stuefe at openjdk.org Thu Sep 19 11:52:39 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 11:52:39 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 11:43:12 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/compressedKlass.cpp line 231: >> >>> 229: // The reason is that we want to avoid, if possible, shifts larger than >>> 230: // a cacheline size. >>> 231: _base = addr; >> >> Why is this important? > > It lessens the cache effects of Klass hyperaligning. Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766688756 From stuefe at openjdk.org Thu Sep 19 11:52:40 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 11:52:40 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 23:53:28 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> JVMCI support > > src/hotspot/share/oops/compressedKlass.hpp line 175: > >> 173: // 5b) if CDS=off: Calls initialize() - here, we have more freedom and, if we want, can choose an encoding >> 174: // base that differs from the reservation base from step (4). That allows us, e.g., to later use >> 175: // zero-based encoding. > > Not for this but is there really any benefit for zero based encoding for klass ids? Yes, I think so. I think the SAP Jit people investigated this when doing the PPC ports. You save at least two instructions, and possibly more, per decode op. You save code size too since you don't need to materialize the 64-bit base immediate. Especially on x64 this can mean easily 11 fewer bytes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766681110 From stuefe at openjdk.org Thu Sep 19 11:52:42 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 11:52:42 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v18] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 10:36:58 GMT, Johan Sj?len wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - fix CompressedClassPointersEncodingScheme yet again for linux aarch64 >> - Fixes post-8340184 >> - Merge upstream up to and including 8340184 >> - Merge remote-tracking branch 'origin/master' into JDK-8305895-v4 >> - Fix test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java >> - Fix loop on aarch64 >> - clarify obscure assert in metasapce setup >> - Rework compressedklass encoding >> - remove stray debug output >> - Fixes post 8338526 >> - ... and 47 more: https://git.openjdk.org/jdk/compare/7849f252...28a26aed > > test/hotspot/gtest/metaspace/test_clms.cpp line 193: > >> 191: >> 192: { >> 193: // Nonclass arena allocation. > > The style in this source file isn't really up to scratch, especially *these* lines. Anyway, it's in the tests, so I'm OK with this being fixed in a follow up RFE. Okay, will fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766686807 From rkennke at openjdk.org Thu Sep 19 11:57:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Sep 2024 11:57:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Thu, 19 Sep 2024 05:03:42 GMT, Stefan Karlsson wrote: >> Yes, I saw that patch. I'm not sure I like the idea of cpu dependent code also doing the encoding. There were some C2 changes related to it that I didn't understand if that scheme required them. I don't see the down side to having the prototype header pre-encoded in the markWord. Seems simpler. > > We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler. We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766697849 From rkennke at openjdk.org Thu Sep 19 12:08:46 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Sep 2024 12:08:46 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v23] In-Reply-To: References: Message-ID: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4 - review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/b25a4b69..0d8a9236 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=21-22 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From coleenp at openjdk.org Thu Sep 19 12:38:48 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 19 Sep 2024 12:38:48 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 11:47:21 GMT, Thomas Stuefe wrote: >> It lessens the cache effects of Klass hyperaligning. > > Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10. Yes, please, not having this code would be really nice. This is difficult code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766753081 From erikj at openjdk.org Thu Sep 19 12:47:35 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Sep 2024 12:47:35 GMT Subject: RFR: 8340418: GHA: MacOS AArch64 bundles can be removed prematurely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 05:51:00 GMT, Aleksey Shipilev wrote: > `remove-bundles` step does not depend on `test-macos-aarch64`, which means it can run before macos-aarch64 tests start to run, which would fail those steps. This is not frequent, but will happen if macos-aarch64 runners are lagging behind to pick up the jobs. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21080#pullrequestreview-2315426269 From erikj at openjdk.org Thu Sep 19 13:08:35 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Sep 2024 13:08:35 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 08:32:38 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... make/modules/jdk.incubator.vector/Lib.gmk line 48: > 46: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ > 47: DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ > 48: CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ I think we prefer using the `C_O_FLAG_*` variables instead of explicitly specifying `-O3`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1766779663 From rcastanedalo at openjdk.org Thu Sep 19 13:12:49 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 19 Sep 2024 13:12:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: Message-ID: <0gatRiYQ3frDnMftpb_WaDolUwcYvBFh5hAp6jY0dzQ=.21d6518e-7217-477e-954f-69fd52eb713e@github.com> On Thu, 19 Sep 2024 11:42:04 GMT, Roman Kennke wrote: > > > I agree that this is the simplest and least intrusive way of getting klass loading working in C2 for this experimental version of the feature. However, the approach seems brittle and error-prone, and it may be hard to maintain in the long run. Therefore, I think that a more principled and robust modeling will be needed, after this PR is integrated, in preparation for the non-experimental version. > > > > > > What do you think about this @rkennke? Do you agree on an alternative modeling of klass loading in C2 (without any reliance on `oopDesc::klass_offset_in_bytes()`) being a pre-condition for a future, non-experimental version of compact headers? > > Yes, that sounds like a good improvement! It'd also clean up C2 considerably - right now there are many places in C2 that rely on klass_offset_in_bytes(). Getting rid of them all would be great, but also seems like a major effort. Could you file an issue to track that future work? Done: https://bugs.openjdk.org/browse/JDK-8340453. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2360945827 From stefank at openjdk.org Thu Sep 19 13:12:50 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Sep 2024 13:12:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 12:35:30 GMT, Coleen Phillimore wrote: >> Note that if we go with my KLUT proposal for post-Lilliput (the GC oop iteration improvements), this will not matter anymore and can be simplified to a fixed shift of 10. > > Yes, please, not having this code would be really nice. This is difficult code. Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766804699 From stuefe at openjdk.org Thu Sep 19 13:37:52 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 19 Sep 2024 13:37:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v21] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 13:08:43 GMT, Stefan Karlsson wrote: >> Yes, please, not having this code would be really nice. This is difficult code. > > Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput. I will do some benchmarks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766848371 From mli at openjdk.org Thu Sep 19 13:50:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 13:50:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 12:52:59 GMT, Erik Joelsson wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > make/modules/jdk.incubator.vector/Lib.gmk line 48: > >> 46: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> 47: DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> 48: CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ > > I think we prefer using the `C_O_FLAG_*` variables instead of explicitly specifying `-O3`. Thanks, do you mean something like below? I'll fix it. CFLAGS := $(CFLAGS_JDKLIB) $(C_O_FLAG_HI) -march=rv64gcv, \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1766874473 From stefank at openjdk.org Thu Sep 19 14:25:52 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 19 Sep 2024 14:25:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com> On Thu, 19 Sep 2024 11:54:50 GMT, Roman Kennke wrote: >> We already have a cpu dependent code for both C1 and the interpreter. Adding cpu dependent code to C2 doesn't make it significantly worse. My latest patch also refactors the code so that C1, interpreter, and C2 all calls into shared functions in the macro assembler. > > We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful. This is my current work-in-progress code: https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2 I've made some large rewrites and are currently running it through functional testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1766934571 From mli at openjdk.org Thu Sep 19 15:03:53 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 15:03:53 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v23] In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> References: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> Message-ID: On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4 > - review feedback In both aarch64.ad and x86_64.ad, `MachUEPNode::format` might need some change accordingly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2361266175 From erikj at openjdk.org Thu Sep 19 16:05:41 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Sep 2024 16:05:41 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 13:47:50 GMT, Hamlin Li wrote: >> make/modules/jdk.incubator.vector/Lib.gmk line 48: >> >>> 46: DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ >>> 47: DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ >>> 48: CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ >> >> I think we prefer using the `C_O_FLAG_*` variables instead of explicitly specifying `-O3`. > > Thanks, do you mean something like below? I'll fix it. > > CFLAGS := $(CFLAGS_JDKLIB) $(C_O_FLAG_HI) -march=rv64gcv, \ Sorry, I had to remind myself of how this works. We actually set this as a separate parameter on the Setup macro: `OPTIMIZATION := HIGH` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1767100590 From mli at openjdk.org Thu Sep 19 16:37:40 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 19 Sep 2024 16:37:40 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 16:02:36 GMT, Erik Joelsson wrote: >> Thanks, do you mean something like below? I'll fix it. >> >> CFLAGS := $(CFLAGS_JDKLIB) $(C_O_FLAG_HI) -march=rv64gcv, \ > > Sorry, I had to remind myself of how this works. We actually set this as a separate parameter on the Setup macro: `OPTIMIZATION := HIGH` Thanks. I'm sorry too, I'm not familiar with the build system. What you expected could be something like below? diff --git a/make/modules/jdk.incubator.vector/Lib.gmk b/make/modules/jdk.incubator.vector/Lib.gmk index 5e52277919a..c6c6103a301 100644 --- a/make/modules/jdk.incubator.vector/Lib.gmk +++ b/make/modules/jdk.incubator.vector/Lib.gmk @@ -41,11 +41,12 @@ endif ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, riscv64)+$(INCLUDE_COMPILER2), true+true+true) $(eval $(call SetupJdkLibrary, BUILD_LIBSLEEF, \ NAME := sleef, \ + OPTIMIZATION := HIGH, \ SRC := libsleef/lib, \ EXTRA_SRC := libsleef/generated, \ DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ - CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ + CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ LIBS := $(JDKLIB_LIBS) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1767158779 From rcastanedalo at openjdk.org Thu Sep 19 17:23:50 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 19 Sep 2024 17:23:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> Message-ID: On Wed, 18 Sep 2024 12:08:46 GMT, Roman Kennke wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2576: >> >>> 2574: } else { >>> 2575: lea(dst, Address(obj, index, Address::lsl(scale))); >>> 2576: ldr(dst, Address(dst, offset)); >> >> Do you have a reproducer (or, better yet, a test case) that exercises this case? I ran Oracle's internal CI tiers 1-5 and could never hit it. Could this happen for x64 as well? > > AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like r27[nklass]+offset, that's why we need to lea the r27[nklass] part first. > Yes, this also happens on x86, but x86 supports rX[nklass]+offset addressing. Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1767315114 From duke at openjdk.org Thu Sep 19 19:23:41 2024 From: duke at openjdk.org (duke) Date: Thu, 19 Sep 2024 19:23:41 GMT Subject: Withdrawn: 8333282: Better warning if newly build JDK fails to run In-Reply-To: References: Message-ID: On Thu, 30 May 2024 15:02:38 GMT, Magnus Ihse Bursie wrote: > If the newly built JDK fails to run ("DOA"), we will get a strange error message about jdk.compiler-gendata errors from make. The reason is not at all obvious. > > Instead, we should make a simple check that we can actually use the new JDK before starting to use it for the first time, and report clearly to the user if this is not the case. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19484 From shade at openjdk.org Fri Sep 20 07:03:39 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 20 Sep 2024 07:03:39 GMT Subject: RFR: 8340418: GHA: MacOS AArch64 bundles can be removed prematurely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 05:51:00 GMT, Aleksey Shipilev wrote: > `remove-bundles` step does not depend on `test-macos-aarch64`, which means it can run before macos-aarch64 tests start to run, which would fail those steps. This is not frequent, but will happen if macos-aarch64 runners are lagging behind to pick up the jobs. All right, I think I'll integrate, since this borders on triviality, and I have one review. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21080#issuecomment-2362972771 From shade at openjdk.org Fri Sep 20 07:03:39 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 20 Sep 2024 07:03:39 GMT Subject: Integrated: 8340418: GHA: MacOS AArch64 bundles can be removed prematurely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 05:51:00 GMT, Aleksey Shipilev wrote: > `remove-bundles` step does not depend on `test-macos-aarch64`, which means it can run before macos-aarch64 tests start to run, which would fail those steps. This is not frequent, but will happen if macos-aarch64 runners are lagging behind to pick up the jobs. This pull request has now been integrated. Changeset: 9d76c7c6 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/9d76c7c60ff3133c1078892d7c50a2cfc9ff9c1b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8340418: GHA: MacOS AArch64 bundles can be removed prematurely Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/21080 From luhenry at openjdk.org Fri Sep 20 09:35:35 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Fri, 20 Sep 2024 09:35:35 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 08:32:38 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Glad to see it come to fruition! ------------- Marked as reviewed by luhenry (Committer). PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2317754680 From rkennke at openjdk.org Fri Sep 20 12:33:50 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 20 Sep 2024 12:33:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> Message-ID: On Thu, 19 Sep 2024 17:20:36 GMT, Roberto Casta?eda Lozano wrote: >> AFAIK, this happens only when using compressed oops with a heap-base in r27. When running with that setting, we would get addresses like r27[nklass] or r27[nklass]+offset, both with scale=8. You would need large heaps, perhaps >4GB, to get this coops setting. The problem with aarch64 is that we can't have an address like r27[nklass]+offset, that's why we need to lea the r27[nklass] part first. >> Yes, this also happens on x86, but x86 supports rX[nklass]+offset addressing. > > Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization. I tried to reproduce for a few hours now using a custom testcase, with no success. I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know. I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further. For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768538965 From erikj at openjdk.org Fri Sep 20 12:37:35 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 20 Sep 2024 12:37:35 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 16:35:14 GMT, Hamlin Li wrote: >> Sorry, I had to remind myself of how this works. We actually set this as a separate parameter on the Setup macro: `OPTIMIZATION := HIGH` > > Thanks. I'm sorry too, I'm not familiar with the build system. > What you expected could be something like below? > > diff --git a/make/modules/jdk.incubator.vector/Lib.gmk b/make/modules/jdk.incubator.vector/Lib.gmk > index 5e52277919a..c6c6103a301 100644 > --- a/make/modules/jdk.incubator.vector/Lib.gmk > +++ b/make/modules/jdk.incubator.vector/Lib.gmk > @@ -41,11 +41,12 @@ endif > ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, riscv64)+$(INCLUDE_COMPILER2), true+true+true) > $(eval $(call SetupJdkLibrary, BUILD_LIBSLEEF, \ > NAME := sleef, \ > + OPTIMIZATION := HIGH, \ > SRC := libsleef/lib, \ > EXTRA_SRC := libsleef/generated, \ > DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ > DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ > - CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ > + CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LIBS := $(JDKLIB_LIBS) \ Yes, exactly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1768546861 From rkennke at openjdk.org Fri Sep 20 15:29:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 20 Sep 2024 15:29:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> Message-ID: On Fri, 20 Sep 2024 12:31:18 GMT, Roman Kennke wrote: >> Thanks @rkennke, I tried running test tiers 1-3 using different compressed OOPs configurations but could not reach this code, unfortunately. Could you provide a reproducer? The reason I am particularly interested is because I'd like to find whether there could be any problematic interaction with C2's implicit null check optimization. > > I tried to reproduce for a few hours now using a custom testcase, with no success. > I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know. > I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further. > > For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738 Something like this is what I have in mind. It seems to pass tier1 tests. I still haven't managed to reproduce the path that requires an index register, though. https://github.com/rkennke/jdk/commit/2c4a7877e4ef94017c8155578d8cfc9342441656 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768816377 From fweimer at openjdk.org Fri Sep 20 16:17:05 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Fri, 20 Sep 2024 16:17:05 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names Message-ID: 8340552: Harden TzdbZoneRulesCompiler against missing zone names ------------- Commit messages: - 8340552: Harden TzdbZoneRulesCompiler against missing zone names Changes: https://git.openjdk.org/jdk/pull/21112/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21112&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340552 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21112/head:pull/21112 PR: https://git.openjdk.org/jdk/pull/21112 From matsaave at openjdk.org Fri Sep 20 17:21:51 2024 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 20 Sep 2024 17:21:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v23] In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> References: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> Message-ID: On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4 > - review feedback CDS changes look good! Have two style comments but otherwise this makes sense ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2318793061 From matsaave at openjdk.org Fri Sep 20 17:21:53 2024 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 20 Sep 2024 17:21:53 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix bit counts in GCForwarding src/hotspot/share/cds/archiveBuilder.cpp line 677: > 675: // Allocate space for the future InstanceKlass with proper alignment > 676: const size_t alignment = > 677: #ifdef _LP64 I think the text alignment here is a bit confusing. Should 678 and 682 be at the same indentation? src/hotspot/share/cds/archiveUtils.cpp line 348: > 346: old_tag = (int)(intptr_t)nextPtr(); > 347: // do_int(&old_tag); > 348: assert(tag == old_tag, "tag doesn't match (%d, expected %d)", old_tag, tag); Is this assert message change a leftover from debugging or is it meant to be this way? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768946883 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768923643 From coleenp at openjdk.org Fri Sep 20 18:19:51 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Sep 2024 18:19:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v23] In-Reply-To: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> References: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> Message-ID: On Thu, 19 Sep 2024 12:08:46 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4 > - review feedback I mostly reviewed the metaspace changes and suggest upstreaming the MetaBlock refactoring ahead of the rest of this patch. Only one comment about the interpreter code (affecting 4 locations). src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3636: > 3634: } else { > 3635: __ sub(r3, r3, sizeof(oopDesc)); > 3636: } This looks like something that could be buggy if we're not careful. We had a pass where we cleaned up sizeof(oopDesc) once. Can this be in oopDesc as (this is not header_size() anymore?) some function with the right name? src/hotspot/cpu/x86/templateTable_x86.cpp line 4121: > 4119: __ movptr(Address(rax, rdx, Address::times_8, sizeof(oopDesc) - 1*oopSize), rcx); > 4120: NOT_LP64(__ movptr(Address(rax, rdx, Address::times_8, sizeof(oopDesc) - 2*oopSize), rcx)); > 4121: } For this and above, I'd rather oopDesc encapsulate the header_size for UseCompactObjectHeaders condition in C++ code, and never see sizeof(oopDesc). src/hotspot/share/memory/metaspace.cpp line 799: > 797: > 798: // Set up compressed class pointer encoding. > 799: // In CDS=off mode, we give the JVM some leeway to choose a favorable base/shift combination. I don't know why this comment is here. Seems out of place. src/hotspot/share/memory/metaspace/freeBlocks.cpp line 57: > 55: } > 56: } > 57: return p; This answers my prior question. The waste is added back to the block list for non-class-arenas as well. src/hotspot/share/memory/metaspace/metablock.hpp line 74: > 72: #define METABLOCKFORMATARGS(__block__) p2i((__block__).base()), (__block__).word_size() > 73: > 74: } // namespace metaspace I am wondering if some of these metaspace changes, that is, the addition of MetaBlock could be upstreamed ahead of the CompactObjectHeaders. Some is refactoring so that you can use the wastage to allocate into class-arena but a lot of this seems neutral to compact object headers, and would reduce this patch and allow different people to focus on just this. src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 470: > 468: > 469: // Returns true if the given block is contained in this arena > 470: // Returns true if the given block is contained in this arena Here's the same comment twice. ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2318539468 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768775590 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768781956 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768979540 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769008437 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769012842 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769015008 From coleenp at openjdk.org Fri Sep 20 18:19:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Sep 2024 18:19:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com> On Wed, 18 Sep 2024 13:57:29 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/classLoaderMetaspace.cpp line 87: >> >>> 85: klass_alignment_words, >>> 86: "class arena"); >>> 87: } >> >> As per my comment in the header file, change the code to this: >> >> ```c++ >> if (class_context != nullptr) { >> // ... Same as in PR >> } else { >> _class_space_arena = _non_class_space_arena; >> } > > Rather not, see reasoning under https://github.com/openjdk/jdk/pull/20677/files#r1754330432 Yes, I'd rather _class_space_arena be nullptr if not used. >> src/hotspot/share/memory/classLoaderMetaspace.cpp line 115: >> >>> 113: if (wastage.is_nonempty()) { >>> 114: non_class_space_arena()->deallocate(wastage); >>> 115: } >> >> This code reads a bit strangely. I understand *what* it tries to do. It tries to give back any wasted memory from either the class space arena *or* the non class space arena to the non class space arena's freelist. I assume that we do this since any wastage is presumably too small to be used by our new 22-bit class pointers. However, this context will be lost on future readers. It should have at least a comment in the `if (wastage.is_nonempty())` clause explaining what we expect should happen and why. For example: >> >> ```c++ >> // Any wasted memory is presumably too small for any class. >> // Therefore, give it back to the non-class space arena's free list. > > Yes. Some background: > > - wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert) > - wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small > > Yes, I will write a better comment. Yes, this definitely needs a comment why since this is how we allocate small chunks of wasted because of hyper-aligning Klasses in class space. Line 111 is somewhat surprising though. I didn't expect there to be wastage from allocating to non-class-metaspace. The unnerving bit of this is that CompressedKlassPointers::is_encodable() is true for memory allocated here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768897591 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768966812 From coleenp at openjdk.org Fri Sep 20 18:19:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Sep 2024 18:19:53 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com> References: <5Mh0IteE4Z7zDseCNMmYKOtyCMTQe0iuAp70kJf8pS0=.8215bcce-6387-46fb-97a0-d1e6a9498b61@github.com> Message-ID: On Fri, 20 Sep 2024 17:34:09 GMT, Coleen Phillimore wrote: >> Yes. Some background: >> >> - wastage can only occur for larger Klass* alignments (aka class space arena alignment property), so only for +COH (note to self, maybe assert) >> - wastage is, by definition, not aligned to the required Klass* alignment, so it cannot be reused. Yes, its probably also too small >> >> Yes, I will write a better comment. > > Yes, this definitely needs a comment why since this is how we allocate small chunks of wasted because of hyper-aligning Klasses in class space. Line 111 is somewhat surprising though. I didn't expect there to be wastage from allocating to non-class-metaspace. > > The unnerving bit of this is that CompressedKlassPointers::is_encodable() is true for memory allocated here. I think this should also assert or be condionalized on UseCompactObjectHeaders. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1768972448 From coleenp at openjdk.org Fri Sep 20 19:02:49 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Sep 2024 19:02:49 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> Message-ID: On Wed, 18 Sep 2024 12:54:34 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/markWord.inline.hpp line 90: >> >>> 88: ShouldNotReachHere(); >>> 89: return markWord(); >>> 90: #endif >> >> Is the ifdef _LP64 necessary, since UseCompactObjectHeaders should always be false for 32 bits? > > Kindof. The problem is that klass_shift is larger than 31, and shifting with it would thus be UB and generate a compiler warning. I opted to simply not compile any of that code in 32bit builds. We could also define klass_shift differently on 32bit. > Long-term (maybe with Lilliput2/4-byte-headers?) it would be nice to consolidate the header layout between 32 and 64 bit builds and not make any distinction anywhere. E.g. define markWord (or objectHeader?) in a single way, and use that to extract all the relevant stuff. It's not totally unlikely that we deprecate 32-bit builds before that can happen, though. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769069007 From coleenp at openjdk.org Fri Sep 20 19:09:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 20 Sep 2024 19:09:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com> References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com> Message-ID: On Thu, 19 Sep 2024 14:22:51 GMT, Stefan Karlsson wrote: >> We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful. > > This is my current work-in-progress code: > https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2 > > I've made some large rewrites and I'm currently running it through functional testing. The refactoring is better in this last version with encode_and_store_compact_object_header, although some comments around the c2 version would be good. Still don't know what the c2 version does. Someone else should review that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1769075714 From naoto at openjdk.org Fri Sep 20 23:25:34 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 20 Sep 2024 23:25:34 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 16:09:13 GMT, Florian Weimer wrote: > 8340552: Harden TzdbZoneRulesCompiler against missing zone names Looks good. Please update the copyright year before the push. Also, add a "noreg-build" label to the JBS issue if you are not going to add a regression test. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21112#pullrequestreview-2319503108 From stuefe at openjdk.org Sun Sep 22 09:52:15 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 22 Sep 2024 09:52:15 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 Message-ID: Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. Tested: with patch fastdebug and release builds are green again. ------------- Commit messages: - start Changes: https://git.openjdk.org/jdk/pull/21119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340574 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21119/head:pull/21119 PR: https://git.openjdk.org/jdk/pull/21119 From stuefe at openjdk.org Sun Sep 22 10:08:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 22 Sep 2024 10:08:33 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. @dholmes-ora maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366523917 From jwaters at openjdk.org Sun Sep 22 11:00:35 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 22 Sep 2024 11:00:35 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: <-1DFUxvGkt-6PGY3zSr4zpQr6tOJavD3EWjVs_EcARE=.3061cd18-8281-4d25-a509-83951e8f87b7@github.com> On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. I think we typically don't use that sort of syntax in make for ifeq, and the quotes around the -O1 shouldn't be necessary too, unless I've missed something. There might be a better way of implementing the check of whether Xcode 16 is being used, but since this is a workaround I think this is ok, we probably wouldn't want to overengineer a hack. My only concern is whether specifying -O1 directly like that will properly end up behind all other optimization flags to properly override them. Other than that, this looks ok ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366726184 From jwaters at openjdk.org Sun Sep 22 11:04:33 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 22 Sep 2024 11:04:33 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. I was about to raise a second concern about Link Time Optimization possibly not working with this patch, but remembered that macOS's only supported compiler, clang, doesn't support LTO in our build system. Wonder how I could've forgotten that ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366727375 From stuefe at openjdk.org Sun Sep 22 11:59:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 22 Sep 2024 11:59:33 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: <5KzXLWYzu_zpbvtUo4VNLYbw_zD76ngass76eGyjnVY=.ebe3d688-fe6b-49fc-b52a-97a1b72e84b2@github.com> On Sun, 22 Sep 2024 11:02:20 GMT, Julian Waters wrote: >> Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. >> >> This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. >> >> Tested: with patch fastdebug and release builds are green again. > > I was about to raise a second concern about Link Time Optimization possibly not working with this patch, but remembered that macOS's only supported compiler, clang, doesn't support LTO in our build system. Wonder how I could've forgotten that @TheShermanTanker > I think we typically don't use that sort of syntax in make for ifeq, Please be more specific. What is "that sort of syntax" you disapprove of? > There might be a better way of implementing the check of whether Xcode 16 is being used, For example? > but since this is a workaround I think this is ok, If its okay, would you mind approving, then? If not, what is preventing approval? I am happy to address any complaints, but yours are way too vague. > we probably wouldn't want to overengineer a hack. My only concern is whether specifying -O1 directly like that will properly end up behind all other optimization flags to properly override them. As I wrote originally: the patch was tested and it works. Moreover, this seems to be the way to do per-file cflag optimization level overrides. > I was about to raise a second concern about Link Time Optimization possibly not working with this patch You are saying that this override mechanism in itself is flawed? If so, it is outside the scope of this RFE and you would need to open a separate JBS issue to address this. For this RFE, I use this mechanism since it has been used for many similar cases (see the other overrides in this file) and it makes my build function again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366749468 From stuefe at openjdk.org Sun Sep 22 12:01:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 22 Sep 2024 12:01:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v6] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 16:56:58 GMT, Matias Saavedra Silva wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bit counts in GCForwarding > > src/hotspot/share/cds/archiveUtils.cpp line 348: > >> 346: old_tag = (int)(intptr_t)nextPtr(); >> 347: // do_int(&old_tag); >> 348: assert(tag == old_tag, "tag doesn't match (%d, expected %d)", old_tag, tag); > > Is this assert message change a leftover from debugging or is it meant to be this way? Its a leftover, but otoh it does not hurt. I found myself re-adding it several times to analyze CDS issues during development, so I decided to just leave it in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1770536320 From jwaters at openjdk.org Sun Sep 22 13:31:37 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 22 Sep 2024 13:31:37 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. Looks ok, though I would recommend switching to ifeq (string1, string2) and dropping the quotes around -O1 ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/21119#pullrequestreview-2320855574 From jwaters at openjdk.org Sun Sep 22 13:31:38 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 22 Sep 2024 13:31:38 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: <5KzXLWYzu_zpbvtUo4VNLYbw_zD76ngass76eGyjnVY=.ebe3d688-fe6b-49fc-b52a-97a1b72e84b2@github.com> References: <5KzXLWYzu_zpbvtUo4VNLYbw_zD76ngass76eGyjnVY=.ebe3d688-fe6b-49fc-b52a-97a1b72e84b2@github.com> Message-ID: On Sun, 22 Sep 2024 11:56:48 GMT, Thomas Stuefe wrote: > Please be more specific. What is "that sort of syntax" you disapprove of? I was referring to the fact that we typically do ifeq (string1, string2) in Makefiles rather than ifeq "string1" "string2" (I probably should have used the GitHub code review feature), was the quote syntax needed for this patch? > You are saying that this override mechanism in itself is flawed? If so, it is outside the scope of this RFE and you would need to open a separate JBS issue to address this. For this RFE, I use this mechanism since it has been used for many similar cases (see the other overrides in this file) and it makes my build function again. Oh, don't mind that, I was just thinking out loud about LTO, I wasn't implying that the mechanism is flawed. Certain areas of the JDK don't have LTO in mind, maybe it's time I looked into that. Either way, I wasn't implying anything was wrong with your patch here > If its okay, would you mind approving, then? Right, I'll do that in a second. My approval won't really do you much good though :P > As I wrote originally: the patch was tested and it works. Moreover, this seems to be the way to do per-file cflag optimization level overrides. That good to hear (I'll look back into SetupNativeCompilation to see if a cleaner way exists, but that's for another PR). Alright, will approve ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366788250 From jwaters at openjdk.org Sun Sep 22 13:41:33 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 22 Sep 2024 13:41:33 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: <5KzXLWYzu_zpbvtUo4VNLYbw_zD76ngass76eGyjnVY=.ebe3d688-fe6b-49fc-b52a-97a1b72e84b2@github.com> Message-ID: On Sun, 22 Sep 2024 13:26:36 GMT, Julian Waters wrote: > As I wrote originally: the patch was tested and it works. Moreover, this seems to be the way to do per-file cflag optimization level overrides. Ah, I remember what I was thinking of now. I was thinking of using BUILD_LIBJVM_stackMapTable.cpp_OPTIMIZATION rather than CXXFLAGS. Unfortunately, as it turns out, with the exception of Microsoft Visual C++, we don't have an optimization level for -O1! As such that approach cannot be used in this patch (Unless -O2 also fixes the issue). What a shame, that would have been cleaner ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366792284 From alanb at openjdk.org Sun Sep 22 15:36:36 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 22 Sep 2024 15:36:36 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: References: <_MLFl-Zir7vvv44qc5hGXChNRhuiwmvTYkXLxVIUFC0=.a6fd655a-6e1a-4704-b317-5a2553a86fd3@github.com> Message-ID: On Fri, 6 Sep 2024 13:16:34 GMT, Kevin Rushforth wrote: >> Looks good. I'll review the CSR when its ready. > >> Looks good. I'll review the CSR when its ready. > > Thanks. > >> The changes to make jdk.jsobject an upgradeable module looks right. > > Thanks for checking. My testing primarily focused on this aspect of the change, so it's pretty well tested. > >> I was initially surprised by the wording "will be delivered with JavaFX" but after playing with a few alternatives I concluded that what we have is okay. > > Yeah, I tried a few variants and couldn't come up with anything better. @kevinrushforth Is the CSR on your list to write? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2366841622 From dholmes at openjdk.org Sun Sep 22 22:29:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Sep 2024 22:29:34 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: <_F6F-JMhg9snB-W-N2a82WBZDEb9IBWmtI2C9GD-OMU=.c2b03f87-ebef-4d59-ae31-da0a52b0d424@github.com> On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. Personally I think it is foolish to trust this compiler and rather than dropping the optimisation level for the one file we've been lucky enough to know has been compiled incorrectly, we should issue a fatal error if this compiler is used. Downgrade your compilers again and complain en-masse to Apple. This compiler simply cannot be trusted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366992837 From duke at openjdk.org Mon Sep 23 01:41:54 2024 From: duke at openjdk.org (SWinxy) Date: Mon, 23 Sep 2024 01:41:54 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path [v3] In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 23:20:03 GMT, Chen Liang wrote: >> Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html >> >> People were confused on a few details around fixing windows space names, including: >> 1. setshortname can report confusing error message when the directory is in use >> 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them >> >> Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update html Bumping to keep this alive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20197#issuecomment-2367098392 From mli at openjdk.org Mon Sep 23 07:30:59 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 07:30:59 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: modify cflags style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/304b74a6..26a68071 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Mon Sep 23 07:30:59 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 07:30:59 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 12:34:38 GMT, Erik Joelsson wrote: >> Thanks. I'm sorry too, I'm not familiar with the build system. >> What you expected could be something like below? >> >> diff --git a/make/modules/jdk.incubator.vector/Lib.gmk b/make/modules/jdk.incubator.vector/Lib.gmk >> index 5e52277919a..c6c6103a301 100644 >> --- a/make/modules/jdk.incubator.vector/Lib.gmk >> +++ b/make/modules/jdk.incubator.vector/Lib.gmk >> @@ -41,11 +41,12 @@ endif >> ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, riscv64)+$(INCLUDE_COMPILER2), true+true+true) >> $(eval $(call SetupJdkLibrary, BUILD_LIBSLEEF, \ >> NAME := sleef, \ >> + OPTIMIZATION := HIGH, \ >> SRC := libsleef/lib, \ >> EXTRA_SRC := libsleef/generated, \ >> DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \ >> - CFLAGS := $(CFLAGS_JDKLIB) -O3 -march=rv64gcv, \ >> + CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> LIBS := $(JDKLIB_LIBS) \ > > Yes, exactly. Modified, Thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1770886456 From luhenry at openjdk.org Mon Sep 23 09:12:36 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 23 Sep 2024 09:12:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: References: Message-ID: <24D2-W-fmlFZ4Ke2wLc-FPKnpskxNIa4aB7NL5ArI8U=.f0e5bdbd-697e-4aea-99ac-1472d14136f7@github.com> On Mon, 23 Sep 2024 07:30:59 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > modify cflags style src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 24: > 22: */ > 23: > 24: #ifdef __riscv_v_intrinsic It would be worth adding a comment on which version of the compiler would be affected, and what would then be the behavior ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1771026089 From kcr at openjdk.org Mon Sep 23 12:51:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 12:51:38 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal In-Reply-To: References: Message-ID: On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. Yes, this was on hold for a couple weeks; I plan to write the CSR this week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2368124430 From erikj at openjdk.org Mon Sep 23 13:12:44 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 23 Sep 2024 13:12:44 GMT Subject: RFR: 8340574: Drop stackMapTable.cpp to -O1 for MacOS on XCode 16 to work around JDK-8340341 In-Reply-To: References: Message-ID: On Sun, 22 Sep 2024 09:46:43 GMT, Thomas Stuefe wrote: > Trivial change to drop the optimization level (for both fastdebug and release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. > > This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which prevents building on MacOS. > > Tested: with patch fastdebug and release builds are green again. make/hotspot/lib/JvmOverrideFiles.gmk line 91: > 89: # See JDK-8340341 > 90: ifeq "$(firstword $(subst ., ,$(CXX_VERSION_NUMBER)))" "16" > 91: BUILD_LIBJVM_stackMapTable.cpp_CXXFLAGS := "-O1" As Julian points out, we don't use quotes in makefiles (as make doesn't treat or interpret quotes a quotes, they are just literal characters). Suggestion: ifeq ($(firstword $(subst ., ,$(CXX_VERSION_NUMBER))), 16) BUILD_LIBJVM_stackMapTable.cpp_CXXFLAGS := -O1 I also kind of agree with David Holmes, this compiler has shown that we can't trust it. At the very least, we should include a big warning somewhere, probably in configure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21119#discussion_r1771384120 From erikj at openjdk.org Mon Sep 23 13:14:39 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 23 Sep 2024 13:14:39 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 07:30:59 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > modify cflags style Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2322170469 From andrew at openjdk.org Mon Sep 23 15:22:40 2024 From: andrew at openjdk.org (Andrew John Hughes) Date: Mon, 23 Sep 2024 15:22:40 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 16:09:13 GMT, Florian Weimer wrote: > 8340552: Harden TzdbZoneRulesCompiler against missing zone names Change looks good to me too. It should help catch issues at build time rather than when the data is used by the JDK. Please bump the copyright header as @naotoj mentions. Not sure how we'd have a regression test for this as it's a tool that runs at build time. Do we have such tests already? ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21112#pullrequestreview-2322622195 From fweimer at openjdk.org Mon Sep 23 15:28:48 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 23 Sep 2024 15:28:48 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names [v2] In-Reply-To: References: Message-ID: > 8340552: Harden TzdbZoneRulesCompiler against missing zone names Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21112/files - new: https://git.openjdk.org/jdk/pull/21112/files/04e2e2e0..92021159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21112&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21112&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21112/head:pull/21112 PR: https://git.openjdk.org/jdk/pull/21112 From fweimer at openjdk.org Mon Sep 23 15:31:35 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 23 Sep 2024 15:31:35 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 16:09:13 GMT, Florian Weimer wrote: > 8340552: Harden TzdbZoneRulesCompiler against missing zone names 920211592d3 should have the current copyright year. This isn't really testable because after a refactoring, the error condition this is guarding against can not happen. Upstream time zone data has had links/aliases to zones removed in OpenJDK since basically forever, so every build exercises this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21112#issuecomment-2368643315 From mli at openjdk.org Mon Sep 23 16:25:02 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 16:25:02 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: <43BqlxIZJ5r6flQcExtgr2OhOc3OPQtsGWeha0G8DeU=.f6ac2d19-50e5-4426-af45-5af367782c8a@github.com> > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/26a68071..f879fa2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=01-02 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Mon Sep 23 16:25:03 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 16:25:03 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: References: Message-ID: <3qDkVnAvugamrnixutLNJPW25dtfZjcCqhnWS33lSVE=.3277081f-189d-4ff6-8bcd-456e8d4eb5af@github.com> On Mon, 23 Sep 2024 07:30:59 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > modify cflags style > Build changes look ok. > > /reviewers 2 Thanks for your reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2368771856 From mli at openjdk.org Mon Sep 23 16:25:03 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 16:25:03 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v2] In-Reply-To: <24D2-W-fmlFZ4Ke2wLc-FPKnpskxNIa4aB7NL5ArI8U=.f0e5bdbd-697e-4aea-99ac-1472d14136f7@github.com> References: <24D2-W-fmlFZ4Ke2wLc-FPKnpskxNIa4aB7NL5ArI8U=.f0e5bdbd-697e-4aea-99ac-1472d14136f7@github.com> Message-ID: On Mon, 23 Sep 2024 09:09:46 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> modify cflags style > > src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 24: > >> 22: */ >> 23: >> 24: #ifdef __riscv_v_intrinsic > > It would be worth adding a comment on which version of the compiler would be affected, and what would then be the behavior Added some comments, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1771751510 From kcr at openjdk.org Mon Sep 23 16:32:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 16:32:23 GMT Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v2] In-Reply-To: References: Message-ID: > Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead. > > See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios. > > This PR does two things: > > 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX > 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself. Kevin Rushforth 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 eight additional commits since the last revision: - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Merge branch 'master' into 8311530-depr-jsobject - Update javadoc - Update copyright years - Merge branch 'master' into 8311530-depr-jsobject - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test - 8311530: Deprecate jdk.jsobject module for removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20555/files - new: https://git.openjdk.org/jdk/pull/20555/files/c3ee6ad3..d2ff851c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=00-01 Stats: 168234 lines in 1172 files changed: 155508 ins; 7077 del; 5649 mod Patch: https://git.openjdk.org/jdk/pull/20555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555 PR: https://git.openjdk.org/jdk/pull/20555 From luhenry at openjdk.org Mon Sep 23 16:44:14 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 23 Sep 2024 16:44:14 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v3] In-Reply-To: <43BqlxIZJ5r6flQcExtgr2OhOc3OPQtsGWeha0G8DeU=.f6ac2d19-50e5-4426-af45-5af367782c8a@github.com> References: <43BqlxIZJ5r6flQcExtgr2OhOc3OPQtsGWeha0G8DeU=.f6ac2d19-50e5-4426-af45-5af367782c8a@github.com> Message-ID: On Mon, 23 Sep 2024 16:25:02 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > comment src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 31: > 29: // bridge functions built in the library, otherwise no such fuctions in the library. > 30: // At runtime, if the library is found and bridge fuctions are found in the library, > 31: // then the java vector API will call into bridge functions and sleef, otherwise not. Suggestion: // At compile-time, if the current compiler does support vector intrinsics, bridge // functions will be built in the library. In case the current compiler doesn't support // vector intrinsics (gcc < 14), then the bridge functions won't be compiled. // At run-time, if the library is found and the bridge functions are available in the // library, then the java vector API will call into the bridge functions and sleef. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1771775908 From jlu at openjdk.org Mon Sep 23 17:29:40 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Sep 2024 17:29:40 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names [v2] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 15:28:48 GMT, Florian Weimer wrote: >> 8340552: Harden TzdbZoneRulesCompiler against missing zone names > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM. I agree that this is difficult to test and being able to build with this change is sufficient testing. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/21112#pullrequestreview-2322899341 From mli at openjdk.org Mon Sep 23 19:32:10 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 19:32:10 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/f879fa2c..32eb54d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Mon Sep 23 19:32:11 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 23 Sep 2024 19:32:11 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: <43BqlxIZJ5r6flQcExtgr2OhOc3OPQtsGWeha0G8DeU=.f6ac2d19-50e5-4426-af45-5af367782c8a@github.com> Message-ID: On Mon, 23 Sep 2024 16:40:55 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> comment > > src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 31: > >> 29: // bridge functions built in the library, otherwise no such fuctions in the library. >> 30: // At runtime, if the library is found and bridge fuctions are found in the library, >> 31: // then the java vector API will call into bridge functions and sleef, otherwise not. > > Suggestion: > > // At compile-time, if the current compiler does support vector intrinsics, bridge > // functions will be built in the library. In case the current compiler doesn't support > // vector intrinsics (gcc < 14), then the bridge functions won't be compiled. > // At run-time, if the library is found and the bridge functions are available in the > // library, then the java vector API will call into the bridge functions and sleef. Thanks for the suggestion, it's much better! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1771970020 From fyang at openjdk.org Tue Sep 24 03:54:48 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 24 Sep 2024 03:54:48 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 19:32:10 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine comment Hi, I have several comments after a cursory look. Please consider. src/hotspot/cpu/riscv/assembler_riscv.hpp line 51: > 49: n_int_register_parameters_c = 8, // x10, x11, ... x17 (c_rarg0, c_rarg1, ...) > 50: n_float_register_parameters_c = 8, // f10, f11, ... f17 (c_farg0, c_farg1, ... ) > 51: n_vector_register_parameters_c = 8, // v8, v9, ... v15 I know vector registers are not used for passing arguments or return values by the RISCV ABI for now. But I guess it might be better and consistent to align with the numbering of integer and floating-point argument registers? That is v10 - v17. src/hotspot/cpu/riscv/riscv.ad line 10078: > 10076: match(CallLeafVector); > 10077: > 10078: effect(USE meth); It's possible for the runtime call to clobber rFlagsReg `cr` (aka `t1`). So safer to add `KILL cr` to the effect. src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 669: > 667: uint num_bits, > 668: uint total_args_passed) { > 669: // More than 8 argument inputs are not supported now. Maybe: `// More than 8 argument inputs are not supported for now.` src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 6063: > 6061: > 6062: void generate_vector_math_stubs() { > 6063: if (UseRVV) { Seems to me cleaner to do this: if (UseRVV) { generate_vector_math_stubs(); } ------------- PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2323927673 PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772520081 PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772527038 PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772521301 PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772522783 From rehn at openjdk.org Tue Sep 24 05:28:36 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 24 Sep 2024 05:28:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 03:45:32 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine comment > > src/hotspot/cpu/riscv/assembler_riscv.hpp line 51: > >> 49: n_int_register_parameters_c = 8, // x10, x11, ... x17 (c_rarg0, c_rarg1, ...) >> 50: n_float_register_parameters_c = 8, // f10, f11, ... f17 (c_farg0, c_farg1, ... ) >> 51: n_vector_register_parameters_c = 8, // v8, v9, ... v15 > > I know vector registers are not used for passing arguments or return values by the RISCV ABI for now. But I guess it might be better and consistent to align with the numbering of integer and floating-point argument registers (x10 - x17, f10 - f17)? That is v10 - v17. Note in the RISC-V ELF psABI there is a convetion variant for v-regs. If you add function attribute riscv_vector_cc it should be used for C/C++. (I never tested it) v0 = first vector mask argument v8-v23 = args/rets v1-v7/v24-v31 = caller saved https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772630985 From rehn at openjdk.org Tue Sep 24 06:00:37 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 24 Sep 2024 06:00:37 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 03:50:29 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine comment > > src/hotspot/cpu/riscv/riscv.ad line 10078: > >> 10076: match(CallLeafVector); >> 10077: >> 10078: effect(USE meth); > > It's possible for the runtime call to clobber rFlagsReg `cr` (aka `t1`). So safer to add `KILL cr` to the effect. Good find, it will definitely be clobbered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772674338 From fyang at openjdk.org Tue Sep 24 07:02:39 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 24 Sep 2024 07:02:39 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 05:25:38 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/assembler_riscv.hpp line 51: >> >>> 49: n_int_register_parameters_c = 8, // x10, x11, ... x17 (c_rarg0, c_rarg1, ...) >>> 50: n_float_register_parameters_c = 8, // f10, f11, ... f17 (c_farg0, c_farg1, ... ) >>> 51: n_vector_register_parameters_c = 8, // v8, v9, ... v15 >> >> I know vector registers are not used for passing arguments or return values by the RISCV ABI for now. But I guess it might be better and consistent to align with the numbering of integer and floating-point argument registers (x10 - x17, f10 - f17)? That is v10 - v17. > > Note in the RISC-V ELF psABI there is a convetion variant for v-regs. > If you add function attribute riscv_vector_cc it should be used for C/C++. (I never tested it) > v0 = first vector mask argument > v8-v23 = args/rets > v1-v7/v24-v31 = caller saved > > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc Ah, I think I missed that. I was reading psABI spec 1.0 release. Thanks for this info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1772742406 From rcastanedalo at openjdk.org Tue Sep 24 09:01:53 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 24 Sep 2024 09:01:53 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v15] In-Reply-To: References: <6UJOrZqmfsJj6pRzMjPdlYt191QgBV6fIv1qJAYsv60=.15284272-464f-4321-b76c-3412dafc6c63@github.com> Message-ID: On Fri, 20 Sep 2024 15:26:36 GMT, Roman Kennke wrote: >> I tried to reproduce for a few hours now using a custom testcase, with no success. >> I am pretty sure that this can happen, that is why I added this code. Originally I had an assert there asserting that index is not used. I do remember that this happens very rarely, and I don't remember the exact condition. Looking at the possible operands in opclass memory, I think this can only happen when we load an nKlass from an address of the form [rX, rY], i.e. the address in rX indexed by rY. This is an odd thing to happen for loadNKlass, I think, because rY should always be klass_offset_in_bytes. Maybe this is possible when we get odd address merges where we get a PhiNode as the offset/index? I don't know. >> I agree, this *might* lead to surprising problems with implicit null-checking, if it is expected that the first instruction in loadNKlass provokes the SIGSEGV. A way around this would be to declare an opclass that is a subset of 'memory' that excludes all operands with index, and match on that. I think this would force the lea as a separate instruction and ensure that we never see such a thing in loadNKlass. However, I would not feel very confident to do that without a reproducer. Let me dig a little further. >> >> For reference, here is my unsuccessful reproducer: https://gist.github.com/rkennke/8a57610d74fcde07a9390f268ec35738 > > Something like this is what I have in mind. It seems to pass tier1 tests. I still haven't managed to reproduce the path that requires an index register, though. > https://github.com/rkennke/jdk/commit/2c4a7877e4ef94017c8155578d8cfc9342441656 Thanks for the update! If there is a path requiring an index register, I would agree on limiting the memory opclass to exclude indices as you suggest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1772945253 From gdams at openjdk.org Tue Sep 24 11:29:06 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 11:29:06 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required Message-ID: Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 ------------- Commit messages: - 8340804: doc/building.md update Xcode instructions to note that full install is required Changes: https://git.openjdk.org/jdk/pull/21154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340804 Stats: 11 lines in 2 files changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21154/head:pull/21154 PR: https://git.openjdk.org/jdk/pull/21154 From rkennke at openjdk.org Tue Sep 24 11:42:30 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 24 Sep 2024 11:42:30 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v24] In-Reply-To: References: Message-ID: <7N9vxRKxAK2GCBNlnU5E0Bj0sGV6_T-2QX9fKCCxlWg=.bdee038b-cee3-4c52-825c-d381d3616092@github.com> > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Improve matching of loadNKlassCompactHeaders on aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/0d8a9236..2c4a7877 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=22-23 Stats: 17 lines in 3 files changed: 5 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From erikj at openjdk.org Tue Sep 24 12:58:36 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Sep 2024 12:58:36 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 11:21:33 GMT, George Adams wrote: > Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. > > See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 doc/building.html line 618: > 616:

The oldest supported version of Xcode is 13.0.

> 617:

You will need to download Xcode either from the App Store or specific > 618: versions can be easily located via https://xcodereleases.com.

If I run `make update-build-docs`, that does not turn into a link tag. Did you hand edit the html or convert it automatically? Suggestion: versions can be easily located via https://xcodereleases.com.

------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773288348 From gdams at openjdk.org Tue Sep 24 12:58:37 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 12:58:37 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 12:53:08 GMT, Erik Joelsson wrote: >> Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. >> >> See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 > > doc/building.html line 618: > >> 616:

The oldest supported version of Xcode is 13.0.

>> 617:

You will need to download Xcode either from the App Store or specific >> 618: versions can be easily located via https://xcodereleases.com.

> > If I run `make update-build-docs`, that does not turn into a link tag. Did you hand edit the html or convert it automatically? > > Suggestion: > > versions can be easily located via https://xcodereleases.com.

sorry I manually make it a link tag, that's incorrect, I'll fix it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773291033 From erikj at openjdk.org Tue Sep 24 12:58:37 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Sep 2024 12:58:37 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: References: Message-ID: <1wJ9enEB5rQFTXFhZfuQ_MjtDQa9FA-B2g6nX0VkrIY=.a66308a4-d05a-4390-a862-5266373301bc@github.com> On Tue, 24 Sep 2024 12:54:49 GMT, George Adams wrote: >> doc/building.html line 618: >> >>> 616:

The oldest supported version of Xcode is 13.0.

>>> 617:

You will need to download Xcode either from the App Store or specific >>> 618: versions can be easily located via https://xcodereleases.com.

>> >> If I run `make update-build-docs`, that does not turn into a link tag. Did you hand edit the html or convert it automatically? >> >> Suggestion: >> >> versions can be easily located via https://xcodereleases.com.

> > sorry I manually make it a link tag, that's incorrect, I'll fix it now. You can make it a link using markdown `[]()` syntax. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773291766 From gdams at openjdk.org Tue Sep 24 12:58:38 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 12:58:38 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: <1wJ9enEB5rQFTXFhZfuQ_MjtDQa9FA-B2g6nX0VkrIY=.a66308a4-d05a-4390-a862-5266373301bc@github.com> References: <1wJ9enEB5rQFTXFhZfuQ_MjtDQa9FA-B2g6nX0VkrIY=.a66308a4-d05a-4390-a862-5266373301bc@github.com> Message-ID: On Tue, 24 Sep 2024 12:55:17 GMT, Erik Joelsson wrote: > You can make it a link using markdown `[]()` syntax. yeah I'll do that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773293082 From jwaters at openjdk.org Tue Sep 24 13:01:36 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 24 Sep 2024 13:01:36 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: References: <1wJ9enEB5rQFTXFhZfuQ_MjtDQa9FA-B2g6nX0VkrIY=.a66308a4-d05a-4390-a862-5266373301bc@github.com> Message-ID: On Tue, 24 Sep 2024 12:56:10 GMT, George Adams wrote: >> You can make it a link using markdown `[]()` syntax. > >> You can make it a link using markdown `[]()` syntax. > > yeah I'll do that I will approve once this is fixed, looks good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773297953 From gdams at openjdk.org Tue Sep 24 13:08:50 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 13:08:50 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v2] In-Reply-To: References: Message-ID: <1Hs7lsGNKzdj03Fl2hs5XJzfdzVNsEpK39OwDFlrqQY=.5cfbab68-eb39-4c91-9d63-7c59467dcccc@github.com> > Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. > > See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 George Adams has updated the pull request incrementally with one additional commit since the last revision: run pandoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21154/files - new: https://git.openjdk.org/jdk/pull/21154/files/6a491bf2..084cf7b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21154&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21154&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21154/head:pull/21154 PR: https://git.openjdk.org/jdk/pull/21154 From jwaters at openjdk.org Tue Sep 24 13:08:50 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 24 Sep 2024 13:08:50 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v2] In-Reply-To: <1Hs7lsGNKzdj03Fl2hs5XJzfdzVNsEpK39OwDFlrqQY=.5cfbab68-eb39-4c91-9d63-7c59467dcccc@github.com> References: <1Hs7lsGNKzdj03Fl2hs5XJzfdzVNsEpK39OwDFlrqQY=.5cfbab68-eb39-4c91-9d63-7c59467dcccc@github.com> Message-ID: On Tue, 24 Sep 2024 13:06:16 GMT, George Adams wrote: >> Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. >> >> See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > run pandoc Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21154#pullrequestreview-2325195639 From gdams at openjdk.org Tue Sep 24 13:08:51 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 13:08:51 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v2] In-Reply-To: References: <1wJ9enEB5rQFTXFhZfuQ_MjtDQa9FA-B2g6nX0VkrIY=.a66308a4-d05a-4390-a862-5266373301bc@github.com> Message-ID: On Tue, 24 Sep 2024 12:59:15 GMT, Julian Waters wrote: >>> You can make it a link using markdown `[]()` syntax. >> >> yeah I'll do that > > I will approve once this is fixed, looks good updated PTAL ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773305793 From gdams at openjdk.org Tue Sep 24 13:36:20 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 13:36:20 GMT Subject: RFR: 8340815: Add SECURITY.md file Message-ID: Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. Screenshot 2024-09-24 at 14 28 37 I've made an exact copy of https://openjdk.org/groups/vulnerability/report which hasn't changed since 2019 so is unlikely to require regular updating. The other option is that we simply provide a link in the security file to this policy on the website? I'm happy with either approach. ------------- Commit messages: - 8340815: Add SECURITY.md file Changes: https://git.openjdk.org/jdk/pull/21155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340815 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21155/head:pull/21155 PR: https://git.openjdk.org/jdk/pull/21155 From gdams at openjdk.org Tue Sep 24 13:48:34 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 13:48:34 GMT Subject: RFR: 8340815: Add SECURITY.md file In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 13:28:47 GMT, George Adams wrote: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've made an exact copy of https://openjdk.org/groups/vulnerability/report which hasn't changed since 2019 so is unlikely to require regular updating. The other option is that we simply provide a link in the security file to this policy on the website? I'm happy with either approach. I think the build label is right here but it could be security ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21155#issuecomment-2371327296 From mli at openjdk.org Tue Sep 24 14:56:28 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 14:56:28 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: misc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/32eb54d5..f190709a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=03-04 Stats: 97 lines in 4 files changed: 49 ins; 44 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Tue Sep 24 14:56:29 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 14:56:29 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 06:59:58 GMT, Fei Yang wrote: >> Note in the RISC-V ELF psABI there is a convention variant for v-regs. >> If you add function attribute riscv_vector_cc it should be used for C/C++. (I never tested it) >> v0 = first vector mask argument >> v8-v23 = args/rets >> v1-v7/v24-v31 = caller saved >> >> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc > > Ah, I think I missed that. I was reading psABI spec 1.0 release. Thanks for this info. Thanks Robbin for helping explaining! minor correction: v1-v7/v24-v31 = callee saved ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773530570 From mli at openjdk.org Tue Sep 24 14:56:30 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 14:56:30 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 05:57:08 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/riscv.ad line 10078: >> >>> 10076: match(CallLeafVector); >>> 10077: >>> 10078: effect(USE meth); >> >> It's possible for the runtime call to clobber rFlagsReg `cr` (aka `t1`). So safer to add `KILL cr` to the effect. > > Good find, it will definitely be clobbered. Thanks for catching! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773531542 From mli at openjdk.org Tue Sep 24 14:56:32 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 14:56:32 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 03:47:41 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine comment > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 6063: > >> 6061: >> 6062: void generate_vector_math_stubs() { >> 6063: if (UseRVV) { > > Seems to me cleaner to do this: > > if (UseRVV) { > generate_vector_math_stubs(); > } As there are several log output in the method, I think it might be better to put them together in this method. But I made some modification so the indentation looks better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773531189 From rehn at openjdk.org Tue Sep 24 15:00:40 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 24 Sep 2024 15:00:40 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 14:52:39 GMT, Hamlin Li wrote: >> Ah, I think I missed that. I was reading psABI spec 1.0 release. Thanks for this info. > > Thanks Robbin for helping explaining! > > minor correction: v1-v7/v24-v31 = callee saved Yes, sorry what I meant, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773539918 From jwaters at openjdk.org Tue Sep 24 15:02:35 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 24 Sep 2024 15:02:35 GMT Subject: RFR: 8340815: Add SECURITY.md file In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 13:28:47 GMT, George Adams wrote: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've made an exact copy of https://openjdk.org/groups/vulnerability/report which hasn't changed since 2019 so is unlikely to require regular updating to stay in sync. The other option is that we simply provide a link in the security file to this policy on the website? I'm happy with either approach. security handles the Java security libs to my knowledge, not vulnerabilities. I think the build group is a good temporary label ------------- PR Comment: https://git.openjdk.org/jdk/pull/21155#issuecomment-2371561301 From fyang at openjdk.org Tue Sep 24 15:16:38 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 24 Sep 2024 15:16:38 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: <-QJaY5cvW3qGmd5Nj9XT4ibBFFrexIfDKzF3JgEKbtg=.b1ce48dc-fcc5-496b-98bc-58dc7ac13308@github.com> On Tue, 24 Sep 2024 14:57:48 GMT, Robbin Ehn wrote: >> Thanks Robbin for helping explaining! >> >> minor correction: v1-v7/v24-v31 = callee saved > > Yes, sorry what I meant, updated. Then why would we put a constraint on the number of supported argument vector registers here (v8-v15 instead of v8-v23)? Could we just support all of them, i.e., v8-v23 to comply with the RISC-V psABI? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773564555 From erikj at openjdk.org Tue Sep 24 15:30:36 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Sep 2024 15:30:36 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v2] In-Reply-To: <1Hs7lsGNKzdj03Fl2hs5XJzfdzVNsEpK39OwDFlrqQY=.5cfbab68-eb39-4c91-9d63-7c59467dcccc@github.com> References: <1Hs7lsGNKzdj03Fl2hs5XJzfdzVNsEpK39OwDFlrqQY=.5cfbab68-eb39-4c91-9d63-7c59467dcccc@github.com> Message-ID: On Tue, 24 Sep 2024 13:08:50 GMT, George Adams wrote: >> Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. >> >> See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > run pandoc doc/building.md line 426: > 424: > 425: You will need to download Xcode either from the App Store or specific versions > 426: can be easily located via the [Xcode Releases](https://xcodereleases.com) website. This file is trying to keep a consistent 80 char line length limit and this line is longer than 80. Suggestion: can be easily located via the [Xcode Releases](https://xcodereleases.com) website. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21154#discussion_r1773591622 From coleenp at openjdk.org Tue Sep 24 15:40:55 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 24 Sep 2024 15:40:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v23] In-Reply-To: References: <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com> Message-ID: On Fri, 20 Sep 2024 18:11:43 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4 >> - review feedback > > src/hotspot/share/memory/metaspace/metablock.hpp line 74: > >> 72: #define METABLOCKFORMATARGS(__block__) p2i((__block__).base()), (__block__).word_size() >> 73: >> 74: } // namespace metaspace > > I am wondering if some of these metaspace changes, that is, the addition of MetaBlock could be upstreamed ahead of the CompactObjectHeaders. Some is refactoring so that you can use the wastage to allocate into class-arena but a lot of this seems neutral to compact object headers, and would reduce this patch and allow different people to focus on just this. For the record, I am fine with these metaspace changes going in with this PR if the timing for that is better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1773607587 From erikj at openjdk.org Tue Sep 24 16:33:40 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Sep 2024 16:33:40 GMT Subject: RFR: 8340815: Add SECURITY.md file In-Reply-To: References: Message-ID: <2nJYCqVlXvMFlHmqYkPZl9ZxAajwzRfTy4Dga3s7dx4=.da8219c1-c002-4615-9c91-0837b931213b@github.com> On Tue, 24 Sep 2024 13:28:47 GMT, George Adams wrote: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've made an exact copy of https://openjdk.org/groups/vulnerability/report which hasn't changed since 2019 so is unlikely to require regular updating to stay in sync. The other option is that we simply provide a link in the security file to this policy on the website? I'm happy with either approach. This kind of change needs to be reviewed by the vulnerability group. I have notified the appropriate people internally. This PR should not be integrated until you get a clear go ahead from them. My personal opinion is that one should always try to avoid duplicating/forking documentation, so if we are to create a security.md file to populate the security tab in GitHub, then it should only contain a link to the official documentation on openjdk.org. You also need to keep in mind that this file would be unique for every update release repository, so any change would need to be backported everywhere. That makes maintaining this kind of information in the project source repository quite impractical. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21155#issuecomment-2371776187 From gdams at openjdk.org Tue Sep 24 17:18:57 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 17:18:57 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v3] In-Reply-To: References: Message-ID: > Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. > > See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 George Adams has updated the pull request incrementally with one additional commit since the last revision: Update building.md Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21154/files - new: https://git.openjdk.org/jdk/pull/21154/files/084cf7b2..32dd4677 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21154&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21154&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21154/head:pull/21154 PR: https://git.openjdk.org/jdk/pull/21154 From erikj at openjdk.org Tue Sep 24 17:40:36 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Sep 2024 17:40:36 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v3] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 17:18:57 GMT, George Adams wrote: >> Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. >> >> See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Update building.md > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21154#pullrequestreview-2325954191 From duke at openjdk.org Tue Sep 24 18:55:35 2024 From: duke at openjdk.org (duke) Date: Tue, 24 Sep 2024 18:55:35 GMT Subject: RFR: 8340804: doc/building.md update Xcode instructions to note that full install is required [v3] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 17:18:57 GMT, George Adams wrote: >> Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. >> >> See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Update building.md > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> @gdams Your change (at version 32dd4677ceff7e9fd626fb8561b49a15cab5beb1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21154#issuecomment-2372059685 From mli at openjdk.org Tue Sep 24 19:12:53 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 19:12:53 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: use all arg v regs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/f190709a..7719b5cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=04-05 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Tue Sep 24 19:12:53 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 24 Sep 2024 19:12:53 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: <-QJaY5cvW3qGmd5Nj9XT4ibBFFrexIfDKzF3JgEKbtg=.b1ce48dc-fcc5-496b-98bc-58dc7ac13308@github.com> References: <-QJaY5cvW3qGmd5Nj9XT4ibBFFrexIfDKzF3JgEKbtg=.b1ce48dc-fcc5-496b-98bc-58dc7ac13308@github.com> Message-ID: On Tue, 24 Sep 2024 15:12:29 GMT, Fei Yang wrote: >> Yes, sorry what I meant, updated. > > Then why would we put a constraint on the number of supported argument vector registers here (v8-v15 instead of v8-v23)? Could we just support all of them, i.e., v8-v23 to comply with the RISC-V psABI? There is no strong reason, just it's sufficient for current implementation. Maybe it's better to use them all in case in the future some other code touch the limit unnecessarily. I'll change it to use all arg v regs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1773897781 From gdams at openjdk.org Tue Sep 24 19:20:11 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 19:20:11 GMT Subject: RFR: 8340815: Add SECURITY.md file [v2] In-Reply-To: References: Message-ID: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've added a simple SECURITY.md file which includes the link to the official policy on the website. George Adams has updated the pull request incrementally with one additional commit since the last revision: switch to link to website ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21155/files - new: https://git.openjdk.org/jdk/pull/21155/files/59767092..ae4be8e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21155&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21155&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 16 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21155/head:pull/21155 PR: https://git.openjdk.org/jdk/pull/21155 From gdams at openjdk.org Tue Sep 24 19:20:11 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 19:20:11 GMT Subject: RFR: 8340815: Add SECURITY.md file In-Reply-To: <2nJYCqVlXvMFlHmqYkPZl9ZxAajwzRfTy4Dga3s7dx4=.da8219c1-c002-4615-9c91-0837b931213b@github.com> References: <2nJYCqVlXvMFlHmqYkPZl9ZxAajwzRfTy4Dga3s7dx4=.da8219c1-c002-4615-9c91-0837b931213b@github.com> Message-ID: <3kn4CFFETogwYUKHufo5pzXyeVsNN771BgZTzK16_fw=.49af1c03-149e-473f-b081-d127c83a5e58@github.com> On Tue, 24 Sep 2024 16:31:00 GMT, Erik Joelsson wrote: > My personal opinion is that one should always try to avoid duplicating/forking documentation, so if we are to create a security.md file to populate the security tab in GitHub, then it should only contain a link to the official documentation on openjdk.org. You also need to keep in mind that this file would be unique for every update release repository, so any change would need to be backported everywhere. That makes maintaining this kind of information in the project source repository quite impractical. Thanks for the feedback, I've updated this PR to simply include a link to the official policy on the website now ------------- PR Comment: https://git.openjdk.org/jdk/pull/21155#issuecomment-2372138025 From gdams at openjdk.org Tue Sep 24 19:38:40 2024 From: gdams at openjdk.org (George Adams) Date: Tue, 24 Sep 2024 19:38:40 GMT Subject: Integrated: 8340804: doc/building.md update Xcode instructions to note that full install is required In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 11:21:33 GMT, George Adams wrote: > Since JDK17 there has been a dependency on metal in the macOS builds which is only available as part of the full Xcode IDE (rather than command-line tools). We currently recommend only installing the command-line tools in the building.md doc which is incorrect. > > See https://github.com/openjdk/jdk/blob/e1c4d3039f6b5106ce3f65d50f607eacc2a8d168/make/autoconf/toolchain.m4#L681 This pull request has now been integrated. Changeset: b639661e Author: George Adams URL: https://git.openjdk.org/jdk/commit/b639661e797fb52ce32ce397a153c886fdc40f53 Stats: 11 lines in 2 files changed: 0 ins; 5 del; 6 mod 8340804: doc/building.md update Xcode instructions to note that full install is required Reviewed-by: erikj, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/21154 From mr at openjdk.org Tue Sep 24 22:28:36 2024 From: mr at openjdk.org (Mark Reinhold) Date: Tue, 24 Sep 2024 22:28:36 GMT Subject: RFR: 8340815: Add SECURITY.md file [v2] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 19:20:11 GMT, George Adams wrote: >> Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. >> >> Screenshot 2024-09-24 at 14 28 37 >> >> I've added a simple SECURITY.md file which includes the link to the official policy on the website. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > switch to link to website Changes requested by mr (Lead). SECURITY.md line 3: > 1: # OpenJDK Vulnerabilities > 2: > 3: Please follow the process outlined in the [OpenJDK Vulnerability Policy](https://openjdk.org/groups/vulnerability/report) to disclose vulnerabilities in the OpenJDK codebase. s/OpenJDK/JDK/ in the title and immediately preceding ?codebase?, please. ?OpenJDK? is the name of a community; ?JDK? is the name of a body of code. Having done that, you could simplify ?in the JDK codebase? simply to ?in the JDK?. ------------- PR Review: https://git.openjdk.org/jdk/pull/21155#pullrequestreview-2326594491 PR Review Comment: https://git.openjdk.org/jdk/pull/21155#discussion_r1774163597 From fyang at openjdk.org Wed Sep 25 02:03:43 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 25 Sep 2024 02:03:43 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <-QJaY5cvW3qGmd5Nj9XT4ibBFFrexIfDKzF3JgEKbtg=.b1ce48dc-fcc5-496b-98bc-58dc7ac13308@github.com> Message-ID: On Tue, 24 Sep 2024 19:09:29 GMT, Hamlin Li wrote: >> Then why would we put a constraint on the number of supported argument vector registers here (v8-v15 instead of v8-v23)? Could we just support all of them, i.e., v8-v23 to comply with the RISC-V psABI? > > There is no strong reason, just it's sufficient for current implementation. > > Maybe it's better to use them all in case in the future some other code touch the limit unnecessarily. I'll change it to use all arg v regs. Thanks for the update. Glad to see it's now fully compliant with the new calling convention variant of RISC-V psABI. I think the code will be easier for others to understand at the same time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1774302338 From fyang at openjdk.org Wed Sep 25 02:31:40 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 25 Sep 2024 02:31:40 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 19:12:53 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > use all arg v regs src/hotspot/cpu/riscv/riscv.ad line 10079: > 10077: match(CallLeafVector); > 10078: > 10079: effect(USE meth, KILL cr); One more question here. I didn't check the details of `CallLeafVector`. Is it safe to assume that `FRM` will be saved and restored before and after the runtime call? Check this: https://bugs.openjdk.org/browse/JDK-8330094 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1774320423 From gdams at openjdk.org Wed Sep 25 06:28:18 2024 From: gdams at openjdk.org (George Adams) Date: Wed, 25 Sep 2024 06:28:18 GMT Subject: RFR: 8340815: Add SECURITY.md file [v3] In-Reply-To: References: Message-ID: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've added a simple SECURITY.md file which includes the link to the official policy on the website. George Adams has updated the pull request incrementally with one additional commit since the last revision: Feedback from Mark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21155/files - new: https://git.openjdk.org/jdk/pull/21155/files/ae4be8e8..9541c78d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21155&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21155&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21155/head:pull/21155 PR: https://git.openjdk.org/jdk/pull/21155 From gdams at openjdk.org Wed Sep 25 06:28:19 2024 From: gdams at openjdk.org (George Adams) Date: Wed, 25 Sep 2024 06:28:19 GMT Subject: RFR: 8340815: Add SECURITY.md file [v2] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 22:25:29 GMT, Mark Reinhold wrote: >> George Adams has updated the pull request incrementally with one additional commit since the last revision: >> >> switch to link to website > > SECURITY.md line 3: > >> 1: # OpenJDK Vulnerabilities >> 2: >> 3: Please follow the process outlined in the [OpenJDK Vulnerability Policy](https://openjdk.org/groups/vulnerability/report) to disclose vulnerabilities in the OpenJDK codebase. > > s/OpenJDK/JDK/ in the title and immediately preceding ?codebase?, please. ?OpenJDK? is the name of a community; ?JDK? is the name of a body of code. > > Having done that, you could simplify ?in the JDK codebase? simply to ?in the JDK?. Updated PTAL ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21155#discussion_r1774572782 From rkennke at openjdk.org Wed Sep 25 12:34:36 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 25 Sep 2024 12:34:36 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v25] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Enforce lightweight locking on 32-bit platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/2c4a7877..cd69da86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=23-24 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Wed Sep 25 12:53:17 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 25 Sep 2024 12:53:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Allow LM_MONITOR on 32-bit platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/cd69da86..4904d433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From andrew at openjdk.org Wed Sep 25 13:07:38 2024 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 25 Sep 2024 13:07:38 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names [v2] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 15:28:48 GMT, Florian Weimer wrote: >> 8340552: Harden TzdbZoneRulesCompiler against missing zone names > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Copyright year change looks good. ------------- Marked as reviewed by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21112#pullrequestreview-2328202443 From mr at openjdk.org Wed Sep 25 13:10:39 2024 From: mr at openjdk.org (Mark Reinhold) Date: Wed, 25 Sep 2024 13:10:39 GMT Subject: RFR: 8340815: Add SECURITY.md file [v3] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 06:28:18 GMT, George Adams wrote: >> Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. >> >> Screenshot 2024-09-24 at 14 28 37 >> >> I've added a simple SECURITY.md file which includes the link to the official policy on the website. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Mark Marked as reviewed by mr (Lead). ------------- PR Review: https://git.openjdk.org/jdk/pull/21155#pullrequestreview-2328208546 From duke at openjdk.org Wed Sep 25 13:17:36 2024 From: duke at openjdk.org (duke) Date: Wed, 25 Sep 2024 13:17:36 GMT Subject: RFR: 8340815: Add SECURITY.md file [v3] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 06:28:18 GMT, George Adams wrote: >> Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. >> >> Screenshot 2024-09-24 at 14 28 37 >> >> I've added a simple SECURITY.md file which includes the link to the official policy on the website. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Mark @gdams Your change (at version 9541c78d4b20346b7fc8369a1ed784b4422df290) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21155#issuecomment-2374056972 From jwaters at openjdk.org Wed Sep 25 13:43:40 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 25 Sep 2024 13:43:40 GMT Subject: RFR: 8340815: Add SECURITY.md file [v3] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 06:28:18 GMT, George Adams wrote: >> Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. >> >> Screenshot 2024-09-24 at 14 28 37 >> >> I've added a simple SECURITY.md file which includes the link to the official policy on the website. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Mark Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21155#pullrequestreview-2328309381 From rcastanedalo at openjdk.org Wed Sep 25 13:54:59 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 25 Sep 2024 13:54:59 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> Message-ID: <2adTLZAwTvFTVNGeR5e9Cef5uNqpsz2haeobLIDZiNI=.cb2bbf0d-5c1b-4583-b4bd-898e0c5cdbb7@github.com> On Fri, 13 Sep 2024 06:43:34 GMT, Roberto Casta?eda Lozano wrote: >> I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP. > > I see, thanks. In that case, I would suggest removing the explicit `UseCompressedClassPointers` test, since it should be implied by `t->isa_narrowklass()`. `check_init()` within `CompressedKlassPointers::shift()` would already fail for the unexpected case where `t->isa_narrowklass() && !UseCompressedClassPointers`, no? I think it would be good to remove the explicit `UseCompressedClassPointers` test as argued above (i.e. revert this change), unless there is any other reason to keep it that I am missing out? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1775277784 From duke at openjdk.org Wed Sep 25 13:57:36 2024 From: duke at openjdk.org (duke) Date: Wed, 25 Sep 2024 13:57:36 GMT Subject: RFR: 8340552: Harden TzdbZoneRulesCompiler against missing zone names [v2] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 15:28:48 GMT, Florian Weimer wrote: >> 8340552: Harden TzdbZoneRulesCompiler against missing zone names > > Florian Weimer has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year @fweimer-rh Your change (at version 920211592d325fbd9b3c47e4e6887ea246f07f56) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21112#issuecomment-2374164228 From mli at openjdk.org Wed Sep 25 14:07:38 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 25 Sep 2024 14:07:38 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 02:29:11 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> use all arg v regs > > src/hotspot/cpu/riscv/riscv.ad line 10079: > >> 10077: match(CallLeafVector); >> 10078: >> 10079: effect(USE meth, KILL cr); > > I haven't checked the details of `CallLeafVector`. One more question here. Is it safe to assume that `FRM` will be saved and restored before and after the runtime call? Check this: https://bugs.openjdk.org/browse/JDK-8330094 Good question! Let me do some further investigation and get back later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1775300239 From rcastanedalo at openjdk.org Wed Sep 25 14:19:54 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 25 Sep 2024 14:19:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Allow LM_MONITOR on 32-bit platforms src/hotspot/share/opto/memnode.cpp line 2256: > 2254: if (!UseCompactObjectHeaders && alloc != nullptr) { > 2255: return TypeX::make(markWord::prototype().value()); > 2256: } Suggestion: make these four lines conditional on `!UseCompactObjectHeaders`, like so: if (!UseCompactObjectHeaders) { Node* alloc = is_new_object_mark_load(); if (alloc != nullptr) { return TypeX::make(markWord::prototype().value()); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1775322670 From erikj at openjdk.org Wed Sep 25 16:27:43 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 25 Sep 2024 16:27:43 GMT Subject: RFR: 8340815: Add SECURITY.md file [v3] In-Reply-To: References: Message-ID: <9I8X8vJot7nSWnLmD8q9t2HL82JbxditkT6FK13mbvI=.e46f8d6e-61aa-4a5a-8fb8-00fa35571e93@github.com> On Wed, 25 Sep 2024 06:28:18 GMT, George Adams wrote: >> Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. >> >> Screenshot 2024-09-24 at 14 28 37 >> >> I've added a simple SECURITY.md file which includes the link to the official policy on the website. > > George Adams has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Mark Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21155#pullrequestreview-2328786049 From gdams at openjdk.org Wed Sep 25 16:27:43 2024 From: gdams at openjdk.org (George Adams) Date: Wed, 25 Sep 2024 16:27:43 GMT Subject: Integrated: 8340815: Add SECURITY.md file In-Reply-To: References: Message-ID: <5i65LPsOkOwsecDDaLv673XZNMTktpbjYLw2ZQY1r30=.4a2324b8-03dd-4367-8ab3-043cffd359ee@github.com> On Tue, 24 Sep 2024 13:28:47 GMT, George Adams wrote: > Currently the [security tab](https://github.com/openjdk/jdk/security) on the GitHub repos is empty with no clear information or links on where to report security vulnerabilities. > > Screenshot 2024-09-24 at 14 28 37 > > I've added a simple SECURITY.md file which includes the link to the official policy on the website. This pull request has now been integrated. Changeset: 0474f020 Author: George Adams Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/0474f020bf276c761f46bc8ba0873ed90a8fd19b Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8340815: Add SECURITY.md file Reviewed-by: mr, jwaters, erikj ------------- PR: https://git.openjdk.org/jdk/pull/21155 From mli at openjdk.org Wed Sep 25 20:13:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 25 Sep 2024 20:13:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 14:04:35 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/riscv.ad line 10079: >> >>> 10077: match(CallLeafVector); >>> 10078: >>> 10079: effect(USE meth, KILL cr); >> >> I haven't checked the details of `CallLeafVector` yet. One more question here. Is it safe to assume that `FRM` will be saved and restored before and after the runtime call? Check this: https://bugs.openjdk.org/browse/JDK-8330094 > > Good question! > Let me do some further investigation and get back later. I see sleef code only set frm to RNE, but I'm not quite sure. Even if we can make sure current sleef only set frm to RNE, seems to me we can not depends on current implement, it could change. Although good news is we don't update sleef regularly. Maybe we should take similar action as call-to-java and return-from-jni? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1775935783 From fyang at openjdk.org Thu Sep 26 02:18:44 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 26 Sep 2024 02:18:44 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 20:10:41 GMT, Hamlin Li wrote: >> Good question! >> Let me do some further investigation and get back later. > > I see sleef code only set frm to RNE, but I'm not quite sure. > Even if we can make sure current sleef only set frm to RNE, seems to me we can not depends on current implement, it could change. Although good news is we don't update sleef regularly. > Maybe we should take similar action as call-to-java and return-from-jni? Just a bit worried about the fact that manipunating CSR could be very costly on RISC-V. Another choice would be adding an assertion about FP rounding mode expecting RNE when returning back from the SLEEF routine. I also checked floating-point intrinsics with `_rm` suffix in the function name in SLEEF src code and only witnessed use of `__RISCV_FRM_RNE`. I didn't see uses of other rounding modes as specified by the rvv-intrinsic-spec [1]. [1] https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/main/doc/rvv-intrinsic-spec.adoc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1776213231 From mli at openjdk.org Thu Sep 26 07:57:37 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 26 Sep 2024 07:57:37 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 02:15:34 GMT, Fei Yang wrote: >> I see sleef code only set frm to RNE, but I'm not quite sure. >> Even if we can make sure current sleef only set frm to RNE, seems to me we can not depends on current implement, it could change. Although good news is we don't update sleef regularly. >> Maybe we should take similar action as call-to-java and return-from-jni? > > Just a bit worried about the fact that manipunating CSR could be very costly on RISC-V. Another choice would be adding an assertion about FP rounding mode expecting RNE when returning back from the SLEEF routine. I also checked floating-point intrinsics with `_rm` suffix in the function name in SLEEF src code and only witnessed use of `__RISCV_FRM_RNE`. I didn't see uses of other rounding modes as specified by the rvv-intrinsic-spec [1]. > > [1] https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/main/doc/rvv-intrinsic-spec.adoc Sounds like a reasonable solution! Anyone has other thoughts please kindly let me know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1776563833 From rcastanedalo at openjdk.org Thu Sep 26 09:07:56 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 26 Sep 2024 09:07:56 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Allow LM_MONITOR on 32-bit platforms src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5692: > 5690: > 5691: void MacroAssembler::load_klass(Register dst, Register src, Register tmp) { > 5692: BLOCK_COMMENT("load_klass"); I am not sure that the complexity of `MacroAssembler::load_klass` and the two `MacroAssembler::cmp_klass` functions warrant adding block comments, but if you prefer to leave them in, could you use opening and closing comments, as in the other functions in this file (e.g. `MacroAssembler::_verify_oop`)? In that case, please update the comment in the two `MacroAssembler::cmp_klass` functions with a more descriptive name than `cmp_klass 1` and `cmp_klass 2`. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5726: > 5724: #ifdef _LP64 > 5725: if (UseCompactObjectHeaders) { > 5726: load_nklass_compact(tmp, obj); Suggestion: assert here that `tmp != noreg`, just like in `MacroAssembler::cmp_klass(Register src, Register dst, Register tmp1, Register tmp2)` below. Perhaps also assert that the input registers are different. src/hotspot/cpu/x86/macroAssembler_x86.hpp line 379: > 377: // Uses tmp1 and tmp2 as temporary registers. > 378: void cmp_klass(Register src, Register dst, Register tmp1, Register tmp2); > 379: The naming of these two functions could be made clearer and more consistent with their documentation. Please consider renaming the four-argument `cmp_klass` function to `cmp_klasses_from_objects` or similar. The notion of "source" and "destination" in the parameter names is unclear, I suggest to just call them `obj`, `obj1`, `obj2` etc. Please also make sure that the parameter names are consistent in the declaration and definition (e.g. `dst` vs `obj`). src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008: > 4006: #ifdef COMPILER2 > 4007: if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) { > 4008: generate_string_indexof(StubRoutines::_string_indexof_array); This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task? src/hotspot/share/opto/memnode.cpp line 1976: > 1974: // The field is Klass::_prototype_header. Return its (constant) value. > 1975: assert(this->Opcode() == Op_LoadX, "must load a proper type from _prototype_header"); > 1976: return TypeX::make(klass->prototype_header()); This code is dead, because by the time we call `load_array_final_field` from `LoadNode::Value` (its only caller) we know that if `UseCompactObjectHeaders`, then `tkls->offset() != in_bytes(Klass::prototype_header_offset()` (or else we would have returned from line 2161). Please remove it, or replace it with an assertion if you prefer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776676785 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776628929 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776644021 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776663594 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776621766 From rcastanedalo at openjdk.org Thu Sep 26 09:54:57 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 26 Sep 2024 09:54:57 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: <4sBfv1qLQjGZnrCuHBPuWp1PNkIDFLBjxMo3z_RR0Mo=.38e699ce-30bc-42fe-86b6-988df6700c82@github.com> On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Allow LM_MONITOR on 32-bit platforms src/hotspot/cpu/x86/x86_64.ad line 4388: > 4386: effect(KILL cr); > 4387: ins_cost(125); // XXX > 4388: format %{ "movl $dst, $mem\t# compressed klass ptr" %} For consistency with the aarch64 back-end: Suggestion: format %{ "load_nklass_compact $dst, $mem\t# compressed klass ptr" %} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776747538 From rkennke at openjdk.org Thu Sep 26 11:41:53 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Sep 2024 11:41:53 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 08:55:44 GMT, Roberto Casta?eda Lozano wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow LM_MONITOR on 32-bit platforms > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008: > >> 4006: #ifdef COMPILER2 >> 4007: if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) { >> 4008: generate_string_indexof(StubRoutines::_string_indexof_array); > > This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task? This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0 If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776888460 From mli at openjdk.org Thu Sep 26 11:53:14 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 26 Sep 2024 11:53:14 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v7] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: check frm after sleef call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/7719b5cf..50b6d529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=05-06 Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From mli at openjdk.org Thu Sep 26 11:53:14 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 26 Sep 2024 11:53:14 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 07:54:32 GMT, Hamlin Li wrote: >> Just a bit worried about the fact that manipunating CSR could be very costly on RISC-V. Another choice would be adding an assertion about FP rounding mode expecting RNE when returning back from the SLEEF routine. I also checked floating-point intrinsics with `_rm` suffix in the function name in SLEEF src code and only witnessed use of `__RISCV_FRM_RNE`. I didn't see uses of other rounding modes as specified by the rvv-intrinsic-spec [1]. >> >> [1] https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/main/doc/rvv-intrinsic-spec.adoc > > Sounds like a reasonable solution! > Anyone has other thoughts please kindly let me know. added some code to check `frm` after sleef calls. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1776903349 From rcastanedalo at openjdk.org Thu Sep 26 12:16:52 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 26 Sep 2024 12:16:52 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 12:53:17 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Allow LM_MONITOR on 32-bit platforms src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2570: > 2568: // we get the heapBase in obj, and the narrowOop+klass_offset_in_bytes/sizeof(narrowOop) in index. > 2569: // When that happens, we need to lea the address into a single register, and subtract the > 2570: // klass_offset_in_bytes, to get the address of the mark-word. Parts of this comment are obsolete after commit 2c4a7877, please update the comment. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 882: > 880: void store_klass(Register dst, Register src); > 881: void cmp_klass(Register oop, Register trial_klass, Register tmp); > 882: void cmp_klass(Register src, Register dst, Register tmp1, Register tmp2); Same suggestion as for the analogous x86 functions: consider renaming the four-argument `cmp_klass` function to `cmp_klasses_from_objects` or similar, and the `src` and `dst` parameters to `oop1` and `oop2` or similar if there is no notion of "source" and "destination". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776927247 PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1776942226 From rcastanedalo at openjdk.org Thu Sep 26 13:07:55 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 26 Sep 2024 13:07:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 11:39:02 GMT, Roman Kennke wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4008: >> >>> 4006: #ifdef COMPILER2 >>> 4007: if ((UseAVX == 2) && EnableX86ECoreOpts && !UseCompactObjectHeaders) { >>> 4008: generate_string_indexof(StubRoutines::_string_indexof_array); >> >> This stub routine should be re-enabled if `UseCompactObjectHeaders` is to become non-experimental and enabled by default in the future. Is there a RFE for this task? > > This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0 > > If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections. I am not familiar with the `indexOf` implementation, but here is a relevant comment that motivates the assertion: https://github.com/openjdk/jdk/pull/16753#discussion_r1592774634. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777033220 From mli at openjdk.org Thu Sep 26 13:14:04 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 26 Sep 2024 13:14:04 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: fix test macro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/50b6d529..0bd263d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From rkennke at openjdk.org Thu Sep 26 14:04:43 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Sep 2024 14:04:43 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v27] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - @robcasloz review comments - Improve CollectedHeap::is_oop() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/4904d433..d48f55d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=25-26 Stats: 86 lines in 10 files changed: 20 ins; 21 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Sep 26 14:00:58 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Sep 2024 14:00:58 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: Message-ID: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> On Thu, 26 Sep 2024 13:04:57 GMT, Roberto Casta?eda Lozano wrote: >> This comes from an assert in `LibraryCallKit::inline_string_indexOfI` and I believe we can perhaps remove that assert and the !UCOH clause. I checked a couple of tests that tripped that assert, and they seem to work fine, and I also checked the code in `LibraryCallKit::inline_string_indexOfI` and `generate_string_indexof_stubs()` and could not find anything obvious that requires the base offset to be >=16. I am not sure why that assert is there. I am now running tier1-4 with that change: https://github.com/rkennke/jdk/commit/7001783e8c11718226506f42b7c1f1fda1af3ad0 >> >> If you know (or find) any reason why we need that assert, please let me know. Otherwise I'd remove it, if you don't have objections. > > I am not familiar with the `indexOf` implementation, but here is a relevant comment that motivates the assertion: https://github.com/openjdk/jdk/pull/16753#discussion_r1592774634. Ok, this is indeed relevant and helpful. This could segfault if we happen to read from the very first object on the heap. I can solve this by allowing to copy only 8 bytes onto the stack: https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 Does this look correct to you? Or better to do it as a follow-up? (It passes a couple of indexOf tests, will run tier1-4 on it). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777134871 From rcastanedalo at openjdk.org Thu Sep 26 16:02:55 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 26 Sep 2024 16:02:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Thu, 26 Sep 2024 13:58:02 GMT, Roman Kennke wrote: > Does this look correct to you? Or better to do it as a follow-up? I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777370316 From rkennke at openjdk.org Thu Sep 26 16:18:58 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Sep 2024 16:18:58 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Thu, 26 Sep 2024 15:59:50 GMT, Roberto Casta?eda Lozano wrote: >> Ok, this is indeed relevant and helpful. This could segfault if we happen to read from the very first object on the heap. I can solve this by allowing to copy only 8 bytes onto the stack: https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 >> >> Does this look correct to you? Or better to do it as a follow-up? >> (It passes a couple of indexOf tests, will run tier1-4 on it). > >> Does this look correct to you? Or better to do it as a follow-up? > > I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement. @sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777396409 From sgibbons at openjdk.org Thu Sep 26 17:27:50 2024 From: sgibbons at openjdk.org (Scott Gibbons) Date: Thu, 26 Sep 2024 17:27:50 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Thu, 26 Sep 2024 16:15:39 GMT, Roman Kennke wrote: >>> Does this look correct to you? Or better to do it as a follow-up? >> >> I do not feel confident enough to review this part. If you want to include https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 in this changeset, I would prefer that the original author of JDK-8320448 or at least someone from Intel reviews it, otherwise I think it is fine to leave it as a follow-up enhancement. > > @sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers. @rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me. I would prefer this approach instead of not generating the IndexOf intrinsic. Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`? I can see benefits to either - which provides more clarity? I like the assert as it makes the intention clear (thanks!). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777485078 From fweimer at openjdk.org Thu Sep 26 22:40:44 2024 From: fweimer at openjdk.org (Florian Weimer) Date: Thu, 26 Sep 2024 22:40:44 GMT Subject: Integrated: 8340552: Harden TzdbZoneRulesCompiler against missing zone names In-Reply-To: References: Message-ID: <5yQ-f_ZrKN9ca80EmjtMwYglkTpuX7EbI2-x1v2lW6A=.964384c1-1a90-49bc-868a-a93762f1f2be@github.com> On Fri, 20 Sep 2024 16:09:13 GMT, Florian Weimer wrote: > 8340552: Harden TzdbZoneRulesCompiler against missing zone names This pull request has now been integrated. Changeset: 1bc13a1c Author: Florian Weimer URL: https://git.openjdk.org/jdk/commit/1bc13a1c10a580f84f1b7686c95344ec2633f611 Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod 8340552: Harden TzdbZoneRulesCompiler against missing zone names Reviewed-by: andrew, jlu, naoto ------------- PR: https://git.openjdk.org/jdk/pull/21112 From fyang at openjdk.org Fri Sep 27 02:28:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Sep 2024 02:28:37 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix test macro src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 51: > 49: // the dynamic rounding mode is always RNE. > 50: > 51: #ifdef DEBUG Question: Should we check for `NDEBUG` macro here instead? I see checks for this macro in the original SLEEF code. #ifndef NDEBUG #define CHECK_FRM __asm__ __volatile__ ( \ " frrm t0 \n\t" \ " beqz t0, 2f \n\t" \ " csrrw x0, cycle, x0 \n\t" \ "2: \n\t" \ : : : "memory" ); #else #define CHECK_FRM #endif ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1777931566 From mli at openjdk.org Fri Sep 27 07:09:42 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 27 Sep 2024 07:09:42 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 02:22:58 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test macro > > src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 51: > >> 49: // the dynamic rounding mode is always RNE. >> 50: >> 51: #ifdef DEBUG > > Question: Should we check for `NDEBUG` macro (A macro specified by C/C++ standard) here instead? I see checks for this macro in the original SLEEF code. > > > #ifndef NDEBUG > #define CHECK_FRM __asm__ __volatile__ ( \ > " frrm t0 \n\t" \ > " beqz t0, 2f \n\t" \ > " csrrw x0, cycle, x0 \n\t" \ > "2: \n\t" \ > : : : "memory" ); > #else > #define CHECK_FRM > #endif `NDEBUG` is only used in sleefdp.c which is the original sleef code, and we don't use that file in jdk directly, in java.base module of jdk it uses `DEBUG` but not use `NDEBUG`. Based on above information, I think `DEBUG` is better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1778114122 From fyang at openjdk.org Fri Sep 27 08:14:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 27 Sep 2024 08:14:37 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 07:06:44 GMT, Hamlin Li wrote: >> src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 51: >> >>> 49: // the dynamic rounding mode is always RNE. >>> 50: >>> 51: #ifdef DEBUG >> >> Question: Should we check for `NDEBUG` macro (A macro specified by C/C++ standard) here instead? I see checks for this macro in the original SLEEF code. >> >> >> #ifndef NDEBUG >> #define CHECK_FRM __asm__ __volatile__ ( \ >> " frrm t0 \n\t" \ >> " beqz t0, 2f \n\t" \ >> " csrrw x0, cycle, x0 \n\t" \ >> "2: \n\t" \ >> : : : "memory" ); >> #else >> #define CHECK_FRM >> #endif > > `NDEBUG` is only used in sleefdp.c which is the original sleef code, and we don't use that file in jdk directly, in java.base module of jdk it uses `DEBUG` but not use `NDEBUG`. > Based on above information, I think `DEBUG` is better. Sounds good. I suppose this `DEBUG` macro will be defined for debug builds, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1778212230 From rkennke at openjdk.org Fri Sep 27 08:27:57 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Sep 2024 08:27:57 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Thu, 26 Sep 2024 17:25:06 GMT, Scott Gibbons wrote: >> @sviswa7 or @asgibbons WDYT about including https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1 as part of compact object headers implementation? Otherwise we would have to disable indexOf intrinsic when running with compact headers, because of the assumption that array headers are >= 16 bytes, which is no longer true with compact headers. > > @rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me. I would prefer this approach instead of not generating the IndexOf intrinsic. > > Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`? I can see benefits to either - which provides more clarity? I like the assert as it makes the intention clear (thanks!). I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point. I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778230714 From mli at openjdk.org Fri Sep 27 09:28:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 27 Sep 2024 09:28:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 08:10:35 GMT, Fei Yang wrote: >> `NDEBUG` is only used in sleefdp.c which is the original sleef code, and we don't use that file in jdk directly, in java.base module of jdk it uses `DEBUG` but not use `NDEBUG`. >> Based on above information, I think `DEBUG` is better. > > Sounds good. I suppose this `DEBUG` macro will be defined for debug builds, right? Yes, I tested on both release and fastdebug version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1778316701 From rkennke at openjdk.org Fri Sep 27 09:41:17 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Sep 2024 09:41:17 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v28] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Disable TestSplitPacks::test4a, failing on aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/d48f55d6..059b1573 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=26-27 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From mbaesken at openjdk.org Fri Sep 27 10:10:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 27 Sep 2024 10:10:06 GMT Subject: RFR: 8341024: [test] build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries Message-ID: The jtreg test build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries (on Linux x86_64). Reason seems to be that the ubsan-enabled binaries are much larger than 'normal' product binaries. (for debug binaries the test is already disabled) Error is : java.lang.OutOfMemoryError: Java heap space at java.base/java.nio.file.Files.read(Files.java:3242) at java.base/java.nio.file.Files.readAllBytes(Files.java:3299) at AbsPathsInImage.scanFile(AbsPathsInImage.java:181) at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:173) at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:153) at java.base/java.nio.file.Files.walkFileTree(Files.java:2810) at java.base/java.nio.file.Files.walkFileTree(Files.java:2881) at AbsPathsInImage.scanFiles(AbsPathsInImage.java:153) at AbsPathsInImage.main(AbsPathsInImage.java:119) at java.base/java.lang.invoke.LambdaForm$DMH/0x00007fb6087003a8.invokeStatic(LambdaForm$DMH) at java.base/java.lang.invoke.LambdaForm$MH/0x00007fb608a2f3d8.invoke(LambdaForm$MH) at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:154) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:573) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.runWith(Thread.java:1589) at java.base/java.lang.Thread.run(Thread.java:1576) Especially the debuginfo file for libjvm.so gets HUGE, and needs a higher Xmx setting for this test. At some later point in time, the test could be rewritten to use less memory when looking into the JDK image files. ------------- Commit messages: - JDK-8341024 Changes: https://git.openjdk.org/jdk/pull/21217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341024 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21217/head:pull/21217 PR: https://git.openjdk.org/jdk/pull/21217 From erikj at openjdk.org Fri Sep 27 12:30:39 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Sep 2024 12:30:39 GMT Subject: RFR: 8341024: [test] build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 10:05:08 GMT, Matthias Baesken wrote: > The jtreg test build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries (on Linux x86_64). > Reason seems to be that the ubsan-enabled binaries are much larger than 'normal' product binaries. > (for debug binaries the test is already disabled) > Error is : > java.lang.OutOfMemoryError: Java heap space > at java.base/java.nio.file.Files.read(Files.java:3242) > at java.base/java.nio.file.Files.readAllBytes(Files.java:3299) > at AbsPathsInImage.scanFile(AbsPathsInImage.java:181) > at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:173) > at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:153) > at java.base/java.nio.file.Files.walkFileTree(Files.java:2810) > at java.base/java.nio.file.Files.walkFileTree(Files.java:2881) > at AbsPathsInImage.scanFiles(AbsPathsInImage.java:153) > at AbsPathsInImage.main(AbsPathsInImage.java:119) > at java.base/java.lang.invoke.LambdaForm$DMH/0x00007fb6087003a8.invokeStatic(LambdaForm$DMH) > at java.base/java.lang.invoke.LambdaForm$MH/0x00007fb608a2f3d8.invoke(LambdaForm$MH) > at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:154) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:573) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) > at java.base/java.lang.Thread.runWith(Thread.java:1589) > at java.base/java.lang.Thread.run(Thread.java:1576) > > Especially the debuginfo file for libjvm.so gets HUGE, and needs a higher Xmx setting for this test. > > At some later point in time, the test could be rewritten to use less memory when looking into the JDK image files. I took a quick look at why I chose to read the full files into memory instead of reading from a stream, and while that could be fixed, at least at first glance it seemed to get rather complicated. This seems like a pretty simple and quick workaround. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21217#pullrequestreview-2333599298 From rcastanedalo at openjdk.org Fri Sep 27 14:35:54 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 27 Sep 2024 14:35:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v28] In-Reply-To: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> References: <-CikzUsH1qKbMujGJQFhaPlKaCUDzqH-jEZNM5BZVQQ=.22d236a1-a69a-42e0-86d1-aa738c6e6e6d@github.com> Message-ID: On Thu, 12 Sep 2024 15:42:59 GMT, Thomas Stuefe wrote: >> src/hotspot/share/opto/machnode.cpp line 390: >> >>> 388: t = t->make_ptr(); >>> 389: } >>> 390: if (t->isa_narrowklass() && CompressedKlassPointers::shift() == 0) { >> >> Does this change have any effect? `UseCompressedClassPointers` should be implied by `t->isa_narrowklass()`. > > I don't remember if this change was a reaction to an error or if I just guarded `CompressedKlassPointers::shift()` with +UseCCP because that is the prerequisite now. Probably the latter. I can remove this. Probably should assert then for +UseCCP. @tstuefe @rkennke what do you think about this suggestion? If there is a known case where `t->isa_narrowklass() && !UseCompressedClassPointers` holds, it should be investigated because it might be a symptom of a larger problem. If there is no such a case, I think the explicit `UseCompressedClassPointers` test should be removed to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778724120 From sgibbons at openjdk.org Fri Sep 27 14:47:51 2024 From: sgibbons at openjdk.org (Scott Gibbons) Date: Fri, 27 Sep 2024 14:47:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Fri, 27 Sep 2024 08:24:50 GMT, Roman Kennke wrote: >> @rkennke I reviewed [rkennke@ 097c2af](https://github.com/rkennke/jdk/commit/097c2afa04397773e514552dfb942aa889bfa2c1) and the code looks good to me. I would prefer this approach instead of not generating the IndexOf intrinsic. >> >> Should the controlling `if` be conditioned on `UseCompactObjectHeaders` instead of `arrayOopDesc::base_offset_in_bytes`? I can see benefits to either - which provides more clarity? I like the assert as it makes the intention clear (thanks!). > > I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point. > > I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement. I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away. The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block. So there will not be an additional branch for the code when it is executed. I'm good with a comment tying `UseCompactObjectHeaders` to the condition. The comment can be removed when the flag is removed. "Ship it" :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778739517 From rkennke at openjdk.org Fri Sep 27 16:25:54 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 27 Sep 2024 16:25:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Fri, 27 Sep 2024 14:44:35 GMT, Scott Gibbons wrote: >> I like to have the functional connection: if - for whatever reason - the array base offset is smaller than 16, we need to deal with that. The reason for this happens to be `UseCompactObjectHeaders`, but that may not be clear to the reader of the code. I could add an `assert(UseCompactObjectHeaders` in that branch to make that connection clear. Also consider that `UseCompactObjectHeaders` is intended to go away at some point. >> >> I wonder if having 2 or 3 branches ahead of the main-loop (which probably doesn't do much, because haystack is <=32 bytes) is a useful approach, or if there may be a better way to get the bytes on the stack? I don't know enough about the implementation to make that judgement. > > I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away. The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block. So there will not be an additional branch for the code when it is executed. > > I'm good with a comment tying `UseCompactObjectHeaders` to the condition. The comment can be removed when the flag is removed. "Ship it" :-) Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like: if (haystack_len <= 8) { // Copy 8 bytes onto stack } else if (haystack_len <= 16) { // Copy 16 bytes onto stack } else { // Copy 32 bytes onto stack } So that is 2 branches in this prologue code instead of originally 1. However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault. I think I need to mull over it some more to come up with a correct fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778874906 From yzheng at openjdk.org Fri Sep 27 16:34:55 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Fri, 27 Sep 2024 16:34:55 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v9] In-Reply-To: <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com> References: <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com> <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com> Message-ID: On Thu, 19 Sep 2024 14:22:51 GMT, Stefan Karlsson wrote: >> We haven't decided whether or not we will git rid of ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank could point you to a WIP branch, if that's helpful. > > This is my current work-in-progress code: > https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2 > > I've made some large rewrites and I'm currently running it through functional testing. If @stefank 's patch does not go in this PR, could you please export `Klass::_prototype_header` to JVMCI? Thanks! diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp index 9d1b8a1cb9f..e462025074f 100644 --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp @@ -278,6 +278,7 @@ nonstatic_field(Klass, _bitmap, uintx) \ nonstatic_field(Klass, _hash_slot, uint8_t) \ nonstatic_field(Klass, _misc_flags._flags, u1) \ + nonstatic_field(Klass, _prototype_header, markWord) \ \ nonstatic_field(LocalVariableTableElement, start_bci, u2) \ nonstatic_field(LocalVariableTableElement, length, u2) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778884055 From fyang at openjdk.org Mon Sep 30 03:21:38 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 30 Sep 2024 03:21:38 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix test macro Thanks for the update. The RISC-V part LGTM. You still need another reviewer for the rest of the change. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2336259918 From shade at openjdk.org Mon Sep 30 08:40:46 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 30 Sep 2024 08:40:46 GMT Subject: RFR: 8341097: GHA: Demote Mac x86 jobs to build only Message-ID: See the discussion in the bug. I think we can stop testing Mac x86 in GHA, leaving only the build jobs. Additional testing: - [x] GHA passes ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/21257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341097 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21257/head:pull/21257 PR: https://git.openjdk.org/jdk/pull/21257 From luhenry at openjdk.org Mon Sep 30 09:04:38 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 30 Sep 2024 09:04:38 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks! >> >> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. >> >> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. >> >> ### Test >> test/jdk/jdk/incubator/vector >> >> ### Performance >> data on bananapi >> >> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 >> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 >> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 >> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 >> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 >> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 >> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 >> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 >> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 >> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 >> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 >> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 >> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 >> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix test macro src/hotspot/share/opto/vectorIntrinsics.cpp line 2044: > 2042: } > 2043: > 2044: if (addr == nullptr && Matcher::supports_scalable_vector()) { Shouldn't this be in the `default` branch of the switch above? Otherwise, we would be hitting the `Unimplemented();` at https://github.com/openjdk/jdk/pull/21083/files#diff-33d0866101d899687e04303fb2232574f2cb796ce060528a243ebdc9903b01b1R2040? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1780704614 From mli at openjdk.org Mon Sep 30 09:36:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 30 Sep 2024 09:36:36 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v8] In-Reply-To: References: Message-ID: <19hPemMkpl_1xHlsjWm0Dc_lpvB4jXG6SoeQUOBkb6A=.ed9843c5-c545-4fda-9b61-df235db6b481@github.com> On Mon, 30 Sep 2024 09:01:24 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test macro > > src/hotspot/share/opto/vectorIntrinsics.cpp line 2044: > >> 2042: } >> 2043: >> 2044: if (addr == nullptr && Matcher::supports_scalable_vector()) { > > Shouldn't this be in the `default` branch of the switch above? Otherwise, we would be hitting the `Unimplemented();` at https://github.com/openjdk/jdk/pull/21083/files#diff-33d0866101d899687e04303fb2232574f2cb796ce060528a243ebdc9903b01b1R2040? Do you mean when the bits > 512, e.g. 1024? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1780753333 From mli at openjdk.org Mon Sep 30 10:33:20 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 30 Sep 2024 10:33:20 GMT Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: Message-ID: <4oXN9TokV6OkJe4BMIF4GBI7g8LA8KZTiZwSksTU_Qw=.6f3da3ea-63f0-472b-8505-d736ab959aa3@github.com> > Hi, > Can you help to review this patch? > Thanks! > > This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api. > > On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions. > > ### Test > test/jdk/jdk/incubator/vector > > ### Performance > data on bananapi > > Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855 > Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001 > Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074 > Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62 > Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166 > Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974 > Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167 > Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219 > Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377 > Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357 > Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398 > Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449 > Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743 > Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743 > Double128Vector.... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: bits > 512 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21083/files - new: https://git.openjdk.org/jdk/pull/21083/files/0bd263d1..0f917561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=07-08 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083 PR: https://git.openjdk.org/jdk/pull/21083 From kbarrett at openjdk.org Mon Sep 30 10:42:36 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 30 Sep 2024 10:42:36 GMT Subject: RFR: 8341097: GHA: Demote Mac x86 jobs to build only In-Reply-To: References: Message-ID: On Mon, 30 Sep 2024 08:36:38 GMT, Aleksey Shipilev wrote: > See the discussion in the bug. I think we can stop testing Mac x86 in GHA, leaving only the build jobs. > > Additional testing: > - [x] GHA passes This change seems premature. Various companies (Oracle, SAP, others?) are still supporting macos-x64 on mainline. Removing this seems to be just asking for more frequent backouts due to x64-specific changes that aren't compatible with clang. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21257#pullrequestreview-2337070818 From shade at openjdk.org Mon Sep 30 11:16:34 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 30 Sep 2024 11:16:34 GMT Subject: RFR: 8341097: GHA: Demote Mac x86 jobs to build only In-Reply-To: References: Message-ID: On Mon, 30 Sep 2024 10:39:33 GMT, Kim Barrett wrote: > This change seems premature. Various companies (Oracle, SAP, others?) are still supporting macos-x64 on mainline. Maybe premature, maybe not. We always run against the runner availability in GHA. AFAIU, MacOS 13 will EOL 3 years after release, so around Oct 2025. I don't mind waiting until next year, but want to point out that the clock is ticking on GHA support for Mac x86, and runner availability will likely get gradually worse. Given that GHA runs for every PR, I prefer to fix GHA relabililty/turnaround issues before they become pain points. > Removing this seems to be just asking for more frequent backouts due to x64-specific changes that aren't compatible with clang. I would assume that clang incompatibilities would be caught as build error/warnings during the build. This PR suggests to only disable the test jobs. Build jobs are still on, and at least some parts of runtime are verified when building the full JDK, e.g. when building jmods/jimages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21257#issuecomment-2382888957 From rcastanedalo at openjdk.org Mon Sep 30 12:40:54 2024 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 30 Sep 2024 12:40:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v11] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 13:20:14 GMT, Emanuel Peter wrote: > Indeed, I could re-enable all tests in: > > ``` > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java > test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java > ``` > > but unfortunately not those others: > > ``` > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java > > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java > ``` > > I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset. > > I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it. @rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine: - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java - test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java Here are the failure details: test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java: 1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java: 1) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteByte1(byte[],byte[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! 2) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteByte2(byte[],byte[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! 3) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong1(byte[],long[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! 4) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong2(byte[],long[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! 5) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong3(byte[],long[])" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! 6) Method "public static void compiler.c2.irTests.TestVectorizationMismatchedAccess.testByteLong5(byte[],long[],int,int)" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 >= 1 [given] - No nodes matched! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java: 1) Method "public int[] compiler.vectorization.runner.LoopCombinedOpTest.multipleOpsWith2DifferentTypesAndComplexExpression()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "sse2", "true"}, counts={"_#STORE_VECTOR#_", ">0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 2) Method "public int[] compiler.vectorization.runner.LoopCombinedOpTest.multipleOpsWith2DifferentTypesAndInvariant()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "sse2", "true"}, counts={"_#STORE_VECTOR#_", ">0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2383072505 From rkennke at openjdk.org Mon Sep 30 17:50:54 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Sep 2024 17:50:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v26] In-Reply-To: References: <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com> Message-ID: On Fri, 27 Sep 2024 16:23:15 GMT, Roman Kennke wrote: >> I believe the code in the patch is good enough as-is, especially if `UseCompactObjectHeaders` is slated to go away. The existing `if` will prevent the < 16 byte header code from being emitted, which is the desired behavior - i.e., if the header size is >= 16, there will be no code emitted to the intrinsic for that block. So there will not be an additional branch for the code when it is executed. >> >> I'm good with a comment tying `UseCompactObjectHeaders` to the condition. The comment can be removed when the flag is removed. "Ship it" :-) > > Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like: > > > if (haystack_len <= 8) { > // Copy 8 bytes onto stack > } else if (haystack_len <= 16) { > // Copy 16 bytes onto stack > } else { > // Copy 32 bytes onto stack > } > > > So that is 2 branches in this prologue code instead of originally 1. > > However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault. > > I think I need to mull over it some more to come up with a correct fix. I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5 The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash). I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1781535745